Okay, that was rude of me - not looking into the zip but only at your inline example - I'm sorry. Now, I see where the misunderstanding on my end was coming from, at least, I hope. As a workaround, you are using the `::: notes` block to define the footnote content. Unfortunately, that wont work in my case, since I'm actually making use of speaker notes, too. Which are defined in exactly that block - al least for revealjs. I probably have to take a deeper look into lua filtering to get a hold on all the footnotes in a section and put them in a footer (or into some other markup) within the section. And I need to prevent the html/revealjs writer to create the endnotes section. Looking at the native output, the endnote section does not even exist in the AST. From the beginning, this was the reason, why I thought making the html/revealjs writer to respect the reference-location option would be preferable compared to a filter-based workaround. BPJ schrieb am Mittwoch, 16. September 2020 um 16:34:19 UTC+2: > Den tis 15 sep. 2020 23:50anna ecke <0x616e6e6...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> skrev: > >> Thank you BP for your input. But I think, we have a small >> misunderstanding here. I was referring to footnotes >> , which is a special type of >> references, I think, not speaker notes. >> > > I too was about *foot*notes, albeit "faked" ones not using Pandoc's native > footnotes. If you test my setup filter and all and look at my example HTML > you will see that. By having the filter replace native Pandoc divs with the > class `notes` with raw HTML for div tags I managed to get an actual div, > rather than an aside/speaker notes, so that I could style the list inside. > Did you perhaps not get the zip archive? > > It may be possible to write a Lua filter so that native notes within each > slide/section can be converted to my "faked" format, but I'm afraid that a > Lua filter would not visit the native note elements in say a section > container as created by `make_sections()` in linear order, so they might > end up in the wrong order in a generated list. Albert can probably answer > whether that problem is still there, or if there is a workaround. Anyway I > tried to convert footnote markers in a paragraph to empty spans with a > `note` class and a sequence of reference footnotes into an ordered list > with Vim `s///` commands and it worked well, so it shouldn't be too hard to > convert existing native notes to my "faked" version with a decent editor or > a text filter script. > > > >> BP schrieb am Montag, 14. September 2020 um 14:17:49 UTC+2: >> >>> On 2020-09-14 00:00, anna ecke wrote: >>> > At the moment, the location where footnotes are rendered into can be >>> > configured with the option reference-location >>> > . >>> Unfortunately, >>> > it only takes effect when rendering markdown. I'd like to get my >>> footnotes >>> > rendered into the same slide it was mentioned/written in. >>> > >>> > My question is now, would it make sense to propose this on github as a >>> > feature request, or should I just go ahead and write a filter for >>> this? I'm >>> > not an Haskell expert and I haven't checked out the code base to look >>> what >>> > needs to be changed to make that kind of behaviour work or what amount >>> of >>> > effort it might take. >>> > >>> > Happy to hear any opinion or even receive links the code responsible >>> for >>> > this or to projects that have solved this already. >>> > >>> > cheers, >>> > ae >>> > >>> >>> Nothing prevents you from constructing your notes manually, placing note >>> references as sequential numbers in the text and a list with each note >>> text at the appropriate list number at the bottom of each slide. >>> Presumably no links between note markers and notes would be needed in a >>> slide show, which makes things easier, although you might want to wrap >>> the note numbers in the text in spans with a class and the lists with >>> notes in divs with another class for styling. >>> >>> Using a little CSS magic and a Lua filter you can both get note >>> references and note list numbers styled and colored appropriately, *and* >>> reveal yourself of the need to insert note numbers manually, although >>> you still need to insert divs with an appropriate class where you want a >>> note reference to appear, and need to make sure that the notes in the >>> list come in the right order relative to the note references in the text >>> of each slide. >>> >>> Something like this: >>> >>> ``````markdown >>> ## Slide heading >>> >>> The text [mentioning]{.note} some [thing]{.note} or [other]{.note} goes >>> here. >>> >>> :::notes >>> >>> 1. Text for note. >>> 2. Text for note. >>> 3. Text for note. >>> >>> ::: >>> `````` >>> >>> and then in some appropriate place some custom CSS: >>> >>> ``````css >>> span.note:after { >>> content: counter(note-ref-counter); >>> vertical-align: super; >>> color: blue; >>> font-size: 50%; >>> } >>> >>> div.notes ol { >>> list-style: none; >>> font-size: 50%; >>> } >>> >>> section.slide, section.title-slide { >>> counter-reset: note-ref-counter note-counter; >>> } >>> >>> div.notes ol li:before { >>> content: counter(note-counter); >>> vertical-align: super; >>> color: blue; >>> display: inline-block; >>> width: 1em; >>> margin-left: -1em; >>> } >>> >>> span.note { >>> counter-increment: note-ref-counter; >>> } >>> >>> div.notes ol li { >>> counter-increment: note-counter; >>> } >>> `````` >>> >>> This should give you blue superscript note markers and blue superscript >>> list markers without any trailing dot, automatically numbered >>> sequentially for each slide. >>> I tried to make the count be for the whole file rather than for each >>> slide, but Chrome insists on resetting the counters to 1 when they have >>> reached 9. Perhaps someone who understands CSS counters better than I do >>> knows how to fix that. >>> >>> Finally you need to apply the following Lua filter when running Pandoc, >>> so that the `
` elements wrapping the note lists really are divs and >>> not `