Dear list, I recently discovered export filters and found some useful applications for them. For instance, the scientific domain I work in (law) uses footnote citations, and in these footnotes we abbreviate some words which would otherwise be written out in ordinary text, like name particles. Since I use org-cite these footnotes are automatically generated. So what I did was to write a filter which abbreviates these words on export in footnotes. I added the filter function to both org-export-filter-footnote-definition-functions and org-export-filter-footnote-reference-functions and indeed, when I export to LaTeX or ODT it does its job just fine. However, when I export to HTML instead, it does not. When I looked at the text passed to the filter when exporting as HTML, it turned out what the function receives is not the content of the footnote, but only the markup for the footnote number. That came a bit by surprise. So, what is the correct way to target the content of a footnote in a filter across backends? Org mode version 9.5 (release_9.5-484-g98588e @ /home/quintus/.emacs.d/org-mode/lisp/) -quintus -- Dipl.-Jur. M. Gülker | https://mg.guelker.eu | PGP: Siehe Webseite Passau, Deutschland | kontakt@guelker.eu | O<
M. ‘quintus’ Gülker writes: > I recently discovered export filters and found some useful applications > for them. For instance, the scientific domain I work in (law) uses > footnote citations, and in these footnotes we abbreviate some words > which would otherwise be written out in ordinary text, like name > particles. Since I use org-cite these footnotes are automatically > generated. So what I did was to write a filter which abbreviates these > words on export in footnotes. I added the filter function to both > org-export-filter-footnote-definition-functions and > org-export-filter-footnote-reference-functions and indeed, when I export > to LaTeX or ODT it does its job just fine. However, when I export to > HTML instead, it does not. When I looked at the text passed to the > filter when exporting as HTML, it turned out what the function receives > is not the content of the footnote, but only the markup for the footnote > number. That came a bit by surprise. > So, what is the correct way to target the content of a footnote in a > filter across backends? Hi, I think a function for `org-export-filter-parse-tree-functions' would work better here. For example, this function replaces "lorem ipsum" with "foo" in all footnote definitions: #+BIND: org-export-filter-parse-tree-functions (fnt-filter-replace) #+begin_src emacs-lisp :exports results :results none (defun fnt-filter-replace (tree backend info) (org-element-map tree 'footnote-definition (lambda (fnt) (let* ((contents (org-element-interpret-data (org-element-contents fnt))) (contents-new (with-temp-buffer (insert contents) (save-excursion (goto-char (point-min)) (while (re-search-forward "lorem ipsum" nil t) (replace-match "foo" t nil))) (org-element-parse-buffer)))) (apply #'org-element-set-contents fnt (list contents-new)))) info) tree) #+end_src Best regards, Juan Manuel
Hi, Am Sonntag, dem 06. März 2022 schrieb Juan Manuel Macías: > I think a function for `org-export-filter-parse-tree-functions' would > work better here. For example, this function replaces "lorem ipsum" with > "foo" in all footnote definitions: I have tried this suggestion, but it does not appear to work with org-cite’s automatically generated footnotes. Text is only changed in ordinary footnotes already present in the org file. When I use org-cite with citeproc.el with a CSL style demanding footnotes, these citational footnotes are generated from the [cite:] constructs somewhere inside org-cite and/or citeproc.el during the export process. These footnotes are apparantly not subject to “org-export-filter-parse-tree-functions”, probably because they are inserted after parsing has completed. That is, what I am after effectively, is post-processing the results generated by org-cite resp. citeproc.el. I have names in my bibliographic database like “Axel von Hellfeld”, which contain the German name particle “von”. Some (not all) citation customs require “von” to be abbreviated to “v.” so that the cited name becomes “v. Hellfeld”. This is not possible with CSL, so I look for another way to automate this during the export process. -quintus -- Dipl.-Jur. M. Gülker | https://mg.guelker.eu | PGP: Siehe Webseite Passau, Deutschland | kontakt@guelker.eu | O<
M. ‘quintus’ Gülker writes:
> That is, what I am after effectively, is post-processing the results
> generated by org-cite resp. citeproc.el. I have names in my
> bibliographic database like “Axel von Hellfeld”, which contain the
> German name particle “von”. Some (not all) citation customs require
> “von” to be abbreviated to “v.” so that the cited name becomes
> “v. Hellfeld”. This is not possible with CSL, so I look for another
> way to automate this during the export process.
I see. Have you tried using `org-export-filter-final-output-functions'?
You can try a find/replace function for the footnotes of final
output. The drawback is that the scope here is broader and
care should be taken with false positives...
Best regards,
Juan Manuel
Dear all, I ought to drive this thread to its completion. What I intend to do is better covered by the new callback functions provided by citeproc-el: <https://github.com/andras-simonyi/citeproc-el/issues/111> -quintus Am Dienstag, dem 08. März 2022 schrieb Juan Manuel Macías: > M. ‘quintus’ Gülker writes: > >> That is, what I am after effectively, is post-processing the results >> generated by org-cite resp. citeproc.el. I have names in my >> bibliographic database like “Axel von Hellfeld”, which contain the >> German name particle “von”. Some (not all) citation customs require >> “von” to be abbreviated to “v.” so that the cited name becomes >> “v. Hellfeld”. This is not possible with CSL, so I look for another >> way to automate this during the export process. > > I see. Have you tried using `org-export-filter-final-output-functions'? > You can try a find/replace function for the footnotes of final > output. The drawback is that the scope here is broader and > care should be taken with false positives... > > Best regards, > > Juan Manuel -- Dipl.-Jur. M. Gülker | https://mg.guelker.eu | PGP: Siehe Webseite Passau, Deutschland | kontakt@guelker.eu | O<