Fields for Zotero

[Michael Stahl]

On 17.08.22 12:49, Phillips Rogfield wrote:
> Hi Michael,
> 
> thanks for your answer.
> 
>  1.
> 
>     My current understanding is that the proposed
>     |com.sun.star.text.TextField.Bibliography| is the implementation for
>     “Insert -> Table of Contents and Index -> Bibliography Entry” of
>     LibreOffice Writer.
>     Is that right?

yes

>     If it is, then it would mean that LibreOffice would manage the
>     citation process (insert citations and bibliography). Right?

yes

>     We don’t want that. We want Zotero to manage it instead. We want
>     Zotero to tell LibreOffice what an inline citation looks like and
>     what a bibliography looks like.
>     The alternative would be to import the Zotero database in
>     LibreOffice, and then tell LibreOffice what the correct citation
>     style is, and keep the database updated when the Zotero database
>     changes, and keep the citation style updated when it changes.
>     That looks too cumbersome.
>     But maybe I’m failing to understand the process, I have no
>     experience with LibreOffice citation management. I have always used
>     Zotero.
> 
>  2.
> 
>         the other option is, you could insert this with arbitrary
>         content via the Fieldmark service, and since about version 7.3
>         this kind of works in the document model and can be stored as an
>         ODF extension in addition to DOCX/RTF.
> 
> That sounds good, but the Fieldmark seems to lack documentation?

yes, it was in a really poor state until recently.

i think by default it should insert a "text fieldmark", which consists 
of 3 dummy characters in the text, corresponding to the 3 "fldChar" 
elements in DOCX.

there are bizarrely-named properties in a container that can be 
retrieved via getParameters() but i don't think they're relevant to text 
fieldmarks.

oh, one problem is there isn't a good way to retrieve the position of 
the separator character currently; it's possible via 
XTextPortionEnumeration (used by ODF export) but that's hardly convenient.

>     however there is currently no implementation of /expanding/ the
>     fieldmark, that is, there is no code to evaluate the fieldmark
>     command and overwrite the fieldmark result.
> 
> I have no idea what that means.
> I’m sorry for my lack of knowledge.

for Writer's native fields, if you go to Tools->Update->Fields it will 
replace the content; this isn't implemented for fieldmarks.

> Does it mean that we can’t, from a LibreOffice Writer Java extension, 
> retrieve the code of the fieldmark and tell LibreOffice what it should 
> print instead of the code?

no, it means you have to do that because Writer won't do it for you.

you can get fieldmark's anchor via XTextRange and then create a cursor 
and move it 1 to the right from the start to insert the command, and 1 
to the left from the end to insert the result.

> If so, on one hand it is exactly what we need, on the other hand it 
> seems it is already working?
> LibreOffice already shows the correct text, not the code.
> I believe it shows the text in the tag |w:fldChar|, not the one in the 
> tag |w:instrTex| (which contains the code).
> Is that correct?

it can show either, you can switch with View->Field Names.

(the user can also edit the field command when it's visible, same as in 
Word.)

> I hereby attach a document with a Zotero inline citation in the 
> Microsoft Word “Fields” format, for reference. We can take it as a 
> reference implementation.

you can insert basically the same thing via the API.  well, the DOCX 
filter used the API to insert it :)

looks like 7.3 can already round-trip this, although it imports the 
field currently in the "old" way: the command is not inserted as 
document text, but as one of those weirdly named parameters as a plain 
string - the import might need a bit of fixing there...

(there's a config setting 
Filter::Microsoft::Import::ForceImportWWFieldsAsGenericFields to force 
DOCX to import every field as a fieldmark with command and result)

debugging tip, you can get an XML dump of document model with Shift+F12 
when you set env var SW_DEBUG=T:

>       <SwTextNode ptr="0x556258bc6830" index="9">
>         <m_Text>Tddest **(Abadie, 2005)* sad</m_Text>
[...]
>     <fieldmarks>
>       <Fieldmark fieldname="vnd.oasis.opendocument.field.UNHANDLED" fieldHelptext="">
>         <MarkBase name="Bookmark">
>           <markPos>
>             <SwPosition nNode="9" nContent="7"/>
>           </markPos>
>           <otherMarkPos>
>             <SwPosition nNode="9" nContent="24"/>
>           </otherMarkPos>
>         </MarkBase>
>         <parameters>
>           <parameter name="vnd.oasis.opendocument.field.code" value=""ADDIN ZOTERO_ITEM CSL_CITATION {\"citationID\": [long text cut] "
>         </parameters>
>       </Fieldmark>

here you can marvel at the fact that somebody thought it a good idea to 
name parameters that have nothing to do with ODF and are for DOCX 
"vnd.oasis.opendocument.*".

> Best.
> 
> On 16/08/2022 12:06, Michael Stahl wrote:
> 
>> On 16.08.22 09:03, Phillips Rogfield wrote:
>>> Hi Miklos,
>>>
>>> thank you very much for your answer!
>>>
>>> Let’s make sure we are on the same page here.
>>>
>>> Zotero is already able to write its citation with LibreOffice.
>>> To do so, it currently uses one of two methods, at user’s choice:
>>> (1) ReferenceMarks, which are NOT compatible with Microsoft Word
>>> (2) Bookmarks, which are SOMEHOW compatible with Microsoft Word, in 
>>> the sense that you can’t put citations in footnotes, and they tend to 
>>> break very easily.
>>>
>>> Instead, the Zotero plugin for Microsoft Word uses:
>>> (1) Fields, which are NOT compatible with LibreOffice
>>> (2) Bookmarks, see above.
>>>
>>> The point of this post is to allow the plugin for LibreOffice to use 
>>> “Fields”.
>>>
>>> In particular, I have to use the UNO interface to write the following 
>>> in the |word/document.xml| file inside a .docx file:
>>>
>>> |<w:r> <w:fldChar w:fldCharType="begin"/> </w:r> <w:r> <w:instrText 
>>> xml:space="preserve"> [some text here] </w:instrText> </w:r> <w:r> 
>>> <w:fldChar w:fldCharType="separate"/> </w:r> <w:r 
>>> w:rsidRPr="007C09F6"> <w:rPr> <w:rFonts w:ascii="Calibri" 
>>> w:hAnsi="Calibri" w:cs="Calibri"/> </w:rPr> <w:t> [some text here] 
>>> </w:t> </w:r> <w:r> <w:fldChar w:fldCharType="end"/> </w:r> |
>>>
>>> would the |com.sun.star.text.TextField.Bibliography| interface allow 
>>> me to write the above code?
>>
>> kind of, there is code to export it as a CITATION field in 
>> DocxAttributeOutput::EndField_Impl in 
>> sw/source/filter/ww8/docxattributeoutput.cxx.
>>
>> the other option is, you could insert this with arbitrary content via 
>> the Fieldmark service, and since about version 7.3 this kind of works 
>> in the document model and can be stored as an ODF extension in 
>> addition to DOCX/RTF.
>>
>> however there is currently no implementation of *expanding* the 
>> fieldmark, that is, there is no code to evaluate the fieldmark command 
>> and overwrite the fieldmark result.
> 
> ​