In my tests on this intriguing problem, I have run up against an obstacle for each of the most obvious solutions:
- when using built-in regex search for footnote anchor numbers,
[0-9]
does not find them;
- and although AltSearch’s
[::Footnote::]
search does find them, this kind of search cannot be used with “back references”.
I have tested a solution that works OUTSIDE of LibreOffice. It requires:
- Saving the file as an
*.fodt
, or “flat” XML file; and
- Using a text editor with regex capabilities to modify that “flat” XML file.
- A “clean” source file, since the chances of success VERY MUCH depend on the nature of the code in this file.
I have put a copy of my test fodt
file on Google Drive if you would like to see or use it. It’s just “Lorem ipsum” with strategically placed footnotes, mostly before the set ,;:.!?
, but also a couple that should not be changed.
My text editor of choice is the lovely Textadept (cross platform) which uses the TRE regex engine. Loading my test-fn-punct0.fodt
file in Textadept, and using this regular expression search string:
(<text:note .*text:note-class="foot.*<text:note-body>\n.*</text:note>)([,;:\.!?])
(including the \n
code is essential) with this as the replace phrase:
\2\1
converts all the pre-punctuation footnotes into post-punctuation footnotes. This file can then be re-opened in LibreOffice Writer for further editing, or “save-as” .odt or whatever you like. The search in the editor looks like this:
Caveat - I have tried this with a “real world” academic article, and … the source code in the fodt
file was a mess. There were loads and loads of <text:span text:style-name="Tnn"> ... </text:span>
wrappers, and I have no idea where they came from or how they’re being used.1 But it means that my regex, above, is pretty useless for this file. If there was a way of cleaning out those “text:span” wrappers (which are everywhere!), then it would be possible.
I don’t know if this is any use for @catbill, but it is at least one “solution”.
1 A little more investigating shows these to be related to officeooo:rsid
numbers and autocreated “styles” – for a description of the “issue” see fdo#68183 – I have posted a Q&A about them which offers a bit of help for getting rid of them.