Quote:
Originally Posted by DaltonST
ZMI uses no "workaround". I do not know where you are getting that unless it is from some old, obsolete post from when ZMI was being first developed.
Zotero is Zotero, Calibre is Calibre, and they do not "link" to each other.
When exporting from Calibre, all of the PDFs are temporarily stored in a temp folder until you open Zotero and import them into Zotero. Then, you have the PDFs in both Zotero and Calibre, separately and independently. The temporary folder is just that: a temporary place to keep the PDFs in the middle of the whole process, and is purged later like any other "trash" would be in your OS.
When you open a PDF in Zotero that originally came from Calibre, Zotero uses the Zotero copy of the PDF that it put in your Zotero database's "storage" folder.
Likewise, when you export from Zotero and import your PDFs into Calibre, Calibre has a copy of the original Zotero PDF along with the Zotero metadata. When you open your PDF in Calibre, it uses only the PDF in the Calibre Library.
You should be using the "embed metadata" tool in Calibre to update the PDF's internal metadata before you export them and then import them into Zotero. Otherwise, when you open the PDF in Zotero, it will not have all of the internal PDF metadata otherwise available in Calibre's metadata.db because it was not first embedded from metadata.db into the .pdf book format prior to exporting.
To reiterate, a Calibre PDF uses only Calibre, and a Zotero PDF uses only Zotero, and they do not "link" to each other once the Zotero import of the RIS file has completed.
Attached is an image from the Original Post that shows what in Zotero came from Calibre. Everything shown in Zotero is entirely stored within Zotero. You could then delete your entire Calibre Library with no impact whatsoever on Zotero once it has finished importing the RIS file.
Added: ZMI was designed to be used with Zotero installed on the same computer system as Calibre. If you are using some "cloud" version of Zotero, then it will probably not work. I tested with Zotero using the latest version for Windows 10 as of the latest release 1.0.59 of ZMI in April 2018. My Zotero database and storage folder were on my SSD.
Added: You mentioned "annotations". If you use the "embed metadata" tool in Calibre, all metadata, including Comments and any Custom Columns containing anything, including "annotations", will be embedded. How the "annotations" got there in the first place (manually or via another plug-in) does not matter. Everything in metadata.db (what you see in the Calibre "Library View" of its GUI) gets embedded. I believe there is a ToolTip in ZMI that says to always "embed metadata" prior to exporting to Zotero. That is true whether you have "annotations" or not. Also, your ZMI configuration for mapping Calibre metadata to the RIS export file must include the source of "annotations" in Calibre that you want in Zotero. Refer to the ZMI RIS Configuration ToolTips and also the images attached to the Original Post.
DaltonST
|
Ahh I see! It seems we have completely different workflows in mind, that's why things were a bit confusing. I don't really have a desire to move
everything out of Calibre permanently, I simply wanted to add my current library as a bunch of references into Zotero without touching the PDF files (but still be able to open them through Zotero, e.g. for jumping to links in extracted annotations).
By "linking", I'm referring to the ability within Zotero to link to an existing file without copying the actual file into Zotero's own library folder. This is done through the GUI by holding Ctrl-Shift while dragging a PDF in, for example. It leaves the original location intact, and only stores its relative location.
If, for example, I navigate to Calibre's library folder and drop the PDF into Zotero in this way, this accomplishes what I want - it's just not viable to do that for a large collection.
I'd hoped that this linking functionality within Zotero would be exposed through its import system or by setting a certain tag to its file path, and it sounds like that's not the case. Thanks anyway!