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.
