Using zotero2remarkable_bridge with RM Paper Pro

[rosoba]

Thanks a lot for this package!

I managed to set it up and run with my new RM paper pro. It did not work out of the box and I had to make a few adaptions. I am not sure if this is due to the compatibility issues with RM 2 or to my own system setup. In particular, there were two issues which I could only detect using a debugger:

1) In the function sync_to_rm - in sync_functions.py, there is a call to file_name = zot.dump(attachment_id, path=temp_path) expecting a return value. However, in my latest version of the pyzotero package 1.5.25 the dump function does not return any value:

        """
        Dump a file attachment to disk, with optional filename and path
        """
        if not filename:
            filename = self.item(itemkey)["data"]["filename"]
        if path:
            pth = os.path.join(path, filename)
        else:
            pth = filename
        file = self.file(itemkey)
        if self.snapshot:
            self.snapshot = False
            pth = pth + ".zip"
        with open(pth, "wb") as f:
            f.write(file)

I fixed it locally. I am just curious if this is some version inconsistency of mine, or a general issue.

2) I cannot retrieve annotated PDF back from RM. When issuing rmapi geta <path_on_rm> to get the annotated file I get the error message: "Failed to generate annotations". This is not related to bridge but probably to an incompatibility of rmapi with RM paper pro. Is it correct? This is not a big problem for me as I can still access the annotated read papers on the RM cloud. Still it would be great if there is some perspective to fix it.

Once again many thanks for this package. If it makes sense, I can contribute my minor fixes.

[opal06]

I need to prefix that I don't have a RM paper pro, so I can only guess to what is going on.

As for 1.: This is interesting, because the code you quoted doesn't seem to line up with the behaviour described in the documentation:

Zotero.dump(itemID[, filename, path]) A convenient wrapper around Zotero.file(). Writes an attachment to disk using the optional path and filename. If neither are supplied, the file is written to the current working directory, and a Zotero.item() call is first made to determine the attachment filename. No error checking is done regarding the path. If successful, the full path including the file name is returned.

Even more interesting is that I can't find any recent commit that would have changed this behaviour, so it should really still be working just as expected. Did you actually get any errors from this while running the program?

As for 2.: It is very much possible that RM changed something in their annotation format to accommodate some feature or requirement of their new device, especially since its main new feature is the colored e-ink. As you can read here, I switched to using rmapi's geta function, which tries to create an annotated file. It might be that rmapi hasn't implemented support for any changes RM might have made and now failes to create the annotated version. This is somewhat unfortunate, as the annotated version rmapi generates is not even used by the program, it just needs the zip folder that is also created.