[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [O] Bug: When exporting to PDF an Org file where multiple footnotes

From: Rasmus
Subject: Re: [O] Bug: When exporting to PDF an Org file where multiple footnotes share the same definition, only the first footnote is clickable [8.3.4 (8.3.4-39-ge0acd8-elpaplus @ /home/jorge/.emacs.d/elpa/org-plus-contrib-20160418/)]
Date: Mon, 25 Apr 2016 15:36:07 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux)


Nicolas Goaziou <address@hidden> writes:

> Rasmus <address@hidden> writes:
>> The transcoded version of the second "[fn:1]", say S2, will be passed to
>> our filter FUN, if FUN is added to
>> org-export-filter-footnote-reference-functions.  But S2 will only contain
>> the estimated number of the footnote¹, e.g. "\footnotemark[1]{}".
> Indeed. I don't know any other way to handle repeated footnote markers
> in LaTeX.

Could we inject labels in all footnotes?  If so we could simply use


In place of


It seems \footref of scrextend.sty has some extra robustness built into it
but until someone complains I think the \textsuperscript hack should be
enough and better then what we’ve got.


     \usepackage{parskip}   % to avoid \noindent 
     \usepackage{scrextend} % to get \footref 
     Text\footnote{\label{org925ce52} Footnote.}\\

>> We could capture the transcoded version of the link "[[f1]]" in FUN, if
>> FUN is added to org-export-filter-link-functions (I think).  But by then
>> we’d only be served a generic reference, e.g. "\ref{org925ce52}".  I don’t
>> know how we’d then differentiate between a link to a footnote and to some
>> other type of element, e.g. a source block.  Hence, it becomes hard to
>> guess when to use e.g. \footref{.} instead of \ref{.}.
> You can retrieve element referenced as "org925ce52" with
>   (cdr (assoc "org925ce52" (plist-get info :internal-references)))

Cool!  I hadn’t noticed that these are part of info.

> It's a bit low-level, but it is useful, it could be factored out as
> a function in "ox.el".

It should be enough to allow Jorge to write a simple filter to address
original issue.


To err is human. To screw up 10⁶ times per second, you need a computer

reply via email to

[Prev in Thread] Current Thread [Next in Thread]