AsciiDoc footnoteref renders without text

[KucharczykL]

Problem Description

Regular text footnote:testid[Footnote text]
More regular text footnote:testid[]

Result:

Regular text [1] More regular text ???

Expected Behaviour

Regular text [1] More regular text [1]

Additional context

• https://github.com/openSUSE/daps/issues/700
• https://docs.asciidoctor.org/asciidoc/latest/macros/footnote/

[tomschr]

@KucharczykL I've inserted the above text in a ADoc file and created HTML and PDF. This is a screenshot from HTML (similar with PDF):

The footnote reference is correctly rendered.

I used the following packages on openSUSE Leap 15.4:

$ rpm -q daps suse-xsl-stylesheets
daps-4.0.beta1-lp154.182.1.noarch
suse-xsl-stylesheets-2.91.2-lp154.1.1.noarch

If you can confirm this, we can close this issue. :slightly_smiling_face:

[KucharczykL]

Hi @tomschr, I cannot confirm that on neither openSUSE Tumbleweed nor in the RN GitLab repo CI. I've created a test MR here: https://gitlab.suse.de/documentation/release-notes-sles/-/merge_requests/343

You can see the failure log in https://gitlab.suse.de/documentation/release-notes-sles/-/jobs/1702745:

Fatal error: The document contains XML errors:
/builds/documentation/release-notes-sles/build/.profiled/noprofile/release-notes.xml:786:50: error: element "footnoteref" not allowed here; expected the element end-tag, text or element "alt", "annotation", "author", "buildtarget", "citetitle", "code", "command", "constant", "date", "editor", "email", "emphasis", "enumidentifier", "enumname", "enumvalue", "envar", "filename", "firstterm", "footnote", "foreignphrase", "function", "glossterm", "guilabel", "guimenu", "indexterm", "inlinemediaobject", "jobtitle", "keycap", "keycombo", "link", "literal", "macroname", "menuchoice", "namespace", "namespacename", "ns:include", "option", "orgname", "package", "parameter", "person", "personname", "phrase", "productname", "productnumber", "prompt", "property", "quote", "remark", "replaceable", "revnumber", "subscript", "superscript", "systemitem", "tag", "templatename", "trademark", "typedefname", "unionname", "uri", "varname" or "xref" (with xmlns:ns="http://www.w3.org/2001/XInclude") /builds/documentation/release-notes-sles/build/.profiled/noprofile/release-notes.xml:786:50: error: attribute "linkend" not allowed here

On Tumbleweed:

> rpm -q daps suse-xsl-stylesheets
daps-4.0.beta1-182.1.noarch
suse-xsl-stylesheets-2.99.20220216-76.1.noarch

[tomschr]

@KucharczykL Thanks for the hint, Lukáš. I've tried it solely with DocBook, not GeekoDoc. In GeekoDoc, footnoteref is not allowed, that's why you see this error.

I've tried some ideas:

1. Validated with DocBook. This works and creates the correct footnotes. However, this is not always an option.
2. Adapted the adoc_postprocess.xsl. I've added a template that matches for footnoteref and transform this element to xref. If I do this, I don't get any validation error anymore, but the footnote indices aren't shown in HTML nor PDF.

It's certainly a stylesheet bug as footnoteref and xref can be used interchangeably. I think, I solve it by allowing footnoteref in GeekoDoc (see above issue).

[KucharczykL]

Hello @tomschr, I've just tested this and it's only partially fixed. If you try to generate this code:

Regular text footnote:testid[Footnote text]
More regular text footnote:testid[]

You get this:

Regular text [1] More regular text [1]

This seems to be correct, but the second link doesn't work! This is the generated HTML:

<p>
    Regular text
    <a href="#ftn.testid" class="footnote">
        <sup class="footnote" id="testid">[1]</sup>
    </a>
More regular text
    <a class="xref" href="#testid"></a>
    <a href="ftn.testid">
        <sup>[1]</sup>
    </a>
</p>

[tomschr]

@KucharczykL Thanks for the wonderful summary! Much appreciated! :+1:

I've created PR #579 as I've spotted a typo. However, I couldn't try it out yet. If you have time, could you have a look and see if that works better? If I'm not completely mistaken, the "#" is missing in front of "ftn.testid" value.

[KucharczykL]

@tomschr Nice, that seems to have fixed! Thank you for such a quick response :slightly_smiling_face: