Open dstillman opened 7 years ago
Not having this is a pain point with Standalone if you're not viewing PDFs in-browser (and find drag and drop difficult).
That exactly describes my circumstance: FF57 on Ubuntu 17.10, running in the Ratpoison WM, viewing PDF files in evince.
I'll note that what could be even better would be to be able to set Zotero as FF's handler for PDFs, and get it to follow the snapshotting algorithm you described above whenever the user (left-) clicks on a .pdf
link. A further step in the toolchain could be to send the PDF onwards from Zotero to a program like evince for viewing, so that the metadata is just silently and automatically recorded every time the user clicks on a PDF, and so that a copy of the PDF is stored in a sensible place in the local file tree.
That is all quite a bit more complicated than the workflow outlined in this issue, but it would optimise my usage scenario (and, I expect many others might feel similarly).
I'll note that what could be even better would be to be able to set Zotero as FF's handler for PDFs
Yeah, that's planned. (That's "add Zotero as PDF handler in Firefox and choose it from the open/save dialog (not currently possible, but planned)" in the FAQ entry I pointed you to.)
This is a subset of https://github.com/zotero/zotero-connectors/issues/86. Handling translators might take longer for the reasons discussed there, but I don't think there's any reason we can't do at least most PDFs now. Not having this is a pain point with Standalone if you're not viewing PDFs in-browser (and find drag and drop difficult).
It seems like we could handle most links just by looking for
.pdf
at the end of the URL, and maybe forPDF
in the link text, and only showing the menu option in that case. Then we can just send it through tosaveSnapshot
with thepdf
flag. If it's not actually a PDF, I think it will be deleted by the client.