Skip to content

Commit

Permalink
Fix note index code to use the LibreOffice internal index property
Browse files Browse the repository at this point in the history
  • Loading branch information
@adomasven
adomasven committed Jul 6, 2019
1 parent ab96d35 commit bb21e3c
Show file tree
Hide file tree
Showing 2 changed files with 3 additions and 5 deletions.
8 changes: 3 additions & 5 deletions build/source/org/zotero/integration/ooo/comp/ReferenceMark.java
View file
Original file line number Diff line number Diff line change
Expand Up @@ -319,11 +319,9 @@ public String getCode() throws Exception {
}

public Integer getNoteIndex() throws Exception {
if(isNote) {
// Only works for numbered notes; won't work if a note is referenced by a letter
try {
return Integer.parseInt(((XFootnote) UnoRuntime.queryInterface(XFootnote.class, text)).getAnchor().getString());
} catch(NumberFormatException e) {}
if (isNote) {
XPropertySet propertySet = UnoRuntime.queryInterface(XPropertySet.class, text);
return (int) (Short) propertySet.getPropertyValue("ReferenceId");
}
return 0;
}
Expand Down
Binary file modified install/Zotero_OpenOffice_Integration.oxt
View file
Binary file not shown.

5 comments on commit bb21e3c

@fbennett
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A side-effect of this fix will be that back-references in note styles that use first-reference-note-number will no longer be guaranteed to align with the note number printed in the text.

For per-page footnote counts, that form of back-reference will be broken anyway (citation would need to track both page and note number, but only tracks the latter), so maybe it's not worth worrying about; but will mention to the CSL group just in case they want to do something with it in future.

@adomasven
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A side-effect of this fix will be that back-references in note styles that use first-reference-note-number will no longer be guaranteed to align with the note number printed in the text.

As far as I know this just brings LibreOffice inline with what Word produces anyway, but I am rather ignorant of CSL and how citeproc works to know what this is about.

We are changing this because citeproc now throws an error and refuses to process citations in note indices are in a wrong/nonsensical order. It has helped us find a bug with note citation ordering in tables in LO, but I would suggest that citeproc should output a warning in the console, rather than resort to throwing an error, since Zotero might not be the only citeproc clients with issues in note index ordering.

@fbennett
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Glad to hear it was useful. You can turn off sanity checking, but out-of-sequence numbering can lead to excessive memory consumption or failure on large documents.

@adomasven
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Glad to hear it was useful. You can turn off sanity checking, but out-of-sequence numbering can lead to excessive memory consumption or failure on large documents.

How do we turn this off if necessary and will citeproc instead produce warnings in the console?

@fbennett
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

From 1.2.13, it will just issue a warning for out-of-sequence numbering. Repeated citation IDs in citationsPre/citation/citationsPost will still throw an error. You can disable both checks by setting a toggle on the processor after instantiation:

    citeproc.opt.development_extensions.strict_inputs = false;

Note that if you set strict_inputs to false, it will completely disable sanity checking, and in that case you're on your own: repeated IDs will most definitely break things inside the processor, although it will try to process the input and may not throw an explicit error.

If the default logging doesn't work, you can redefine CSL.debug.

Please sign in to comment.