New Cite with Local Zotero in Collabora extension

Development
1

Hello,

I’ve made a new Firefox/Chrome extension that provides fast integration with Zotero for Collabora users using any WOPI service, whether or not they are on Nextcloud, by interfacing directly with a local installation of Zotero (rather than the Nextcloud-only *richdocuments* plugin, which goes via the Web API so is slow and rate-limited and fails with large libraries). It also supports footnote citation methods. It is fully interoperable with the LibreOffice plugin so you should be able to edit an .odt doc between one or the other. Furthermore, unlike the richdocuments plugin, once it is set up, anyone can use it — whereas the richdocuments plugin required you be a user on that Nextcloud instance. So people can collaborate using Zotero, anonymously, using share links, as long as they have the extension, much as they can with the Google Docs plugin.

Plugin pending approval in Firefox and Chrome add-in stores (‘Cite with Local Zotero in Collabora’), you can find it here https://github.com/veale/connector-for-zotero-collabora/ in the meantime if you want to test.

While the Zotero GDocs connector plugin controls GDocs via the DOM, that’s not possible in Collabora. Instead, this uses commands that go to and from two python scripts, that your admin will need to put on the Collabora instance in the trusted scripts library (they will also need to ensure that your Collabora instance can run such scripts from a trusted location, which means they need to set Collabora macro security to level 3 or lower (‘High’) rather than level 4 (‘Very High’). Unfortunately, this is required, as Collabora does not surface commands that you can call from the browser that return information about a document (e.g., what field a cursor is on). If it did, it could all be bundled in the extension, but the relevant UNO commands do not provide feedback, which Zotero needs.

Thoughts welcome! I know it is a different philosophy from the existing integration. It would be great if the python scripts were not needed.

1 Like
2

hi @michaelveale

First of all welcome to the collabora online community :slight_smile:

This is really nice work. Thanks for sharing it. The approach of talking directly to a local Zotero instance rather than going through the Web API makes a lot of sense, especially for larger libraries, and it’s great that it works across WOPI hosts rather than being tied to Nextcloud.

I’m curious about the Python scripts side of things. Could you say a bit more about exactly which document state you need back? You mentioned field-at-cursor — is there a fuller list of what Zotero requires? That would help us think about whether there’s a realistic path to exposing enough from the browser side that the scripts wouldn’t be needed.

Curious to get reply from you :slight_smile:

Happy hacking :purple_heart:

Thanks
Darshan

3

sure! @darshan Here’s what would be needed I think:

reference marks (every citation is stored as one):

  • List all reference mark names in the document

  • Retrieve a specific reference mark by name

  • Get the text string wrapped by a reference mark

  • Create a new com.sun.star.text.ReferenceMark at a given position, wrapping specified text

  • There’s no rename or replace API in UNO, so the script removes the old mark and creates a new one with a different name but same position/text. collabora could ideally offer an atomic rename.

  • remove the mark wrapper only (leaving the text as plain text), or remove both the mark and its text

  • return reference marks sorted by document position (needed by many citation styles for numbering)

Text sections (bibliographies are stored as text:section elements):

A similar set of operations is needed for text sections, since that’s what LibreOffice uses for bibliographies. there also needs to be a way to apply paragraph styles to individual paragraphs within a section.

Custom document properties: Zotero stores its preferences, citation style, field type, locale, etc, in user-defined document properties named ZOTERO_PREF_1, ZOTERO_PREF_2 chunked at 255 chars

  • Read a custom document property by name

  • Write/create a custom document property

  • Delete a custom document property

  • List/check existence of custom document properties

Footnotes and endnotes (many citation styles place references in footnotes, like oscola (i’m a legal academic)):

  • Insert content into a footnote/endnote body — place a reference mark inside the footnote text

  • Enumerate footnotes/endnotes

  • Detect whether a reference mark lives inside a footnote or endnote

  • Delete a footnote/endnote — when converting from footnote back to in-text

  • Get the anchor position of a footnote in the main text — so a new in-text reference mark can be placed at the same location

Cursor/selection awareness (needed for editing existing citations):

  • Get the current cursor/selection position and insert content at the current cursor position

  • Detect if cursor is inside a reference mark eg by comparing cursor position against each mark’s anchor range

  • Select a reference mark: move the view cursor to highlight a specific field

There are a few other things from coverting docs between word and libreoffice formats but that could be handled in libreoffice for those who need it really. Also it would be nice if bookmarks not just reference marks were supported; bookmarks are interoperable between libreoffice and word although have issues like no support in footnotes and so on, but users might inherit files that they want to edit and so bookmark support in the same way as referencemark support would help that.