Footnotes

[vkbo]

Add footnote support using the kramdown mrkdown syntax of [^label] to point to a labelled footnote, and the footnote being specified with the [^label]: syntax where the footnote text are the following indented paragraphs.

See kramdown docs

Since novelWriter doesn't necessarily use a fixed width font, indentation as group indicator isn't ideal. Some solutions may be:

• Only allow a single paragraph for a footnote, like we do for synopsis.
• Same as above, but allow multiple definitions with the same label, which are then appended as separate paragraphs (not very elegant).
• The default is first point, but if no text follows on the same line, all following paragraphs are considered part of the footonote until we either see a new footnote definition label, a heading, or reach the end of the file. This works fairly well if the user always puts the footnotes at the end of the header section they're working on. It is not an unreasonable requirement.
• A modification of the above may be to have a file layout only for footnote definitions, and each note is defined by the area between one label definition and the next. This is definitely the cleanest option, but it removes the flexibility of putting the footnote in the same file where you're referring to it. This makes writing them easier, but may make it more difficult to find where you defined them.

I'm leaning towards the fourth option. Footnotes are defined in files with the FOOTNOTE layout. Each footnote contains all text following a label definition until a new one is defined, or the end of the file is reached. Multiple footnote files are allowed.

Distinguishing between page notes, chapter notes and end notes may be desirable. This can be achieved globally as a single setting as you don't want to use both.

[johnblommers]

I've made extensive use of footnotes in Markdown. I place the footnote text near the [^LABEL] itself, typically at the end of the nearest paragraph following it, so I can find it easily. I never gather the footnotes into dedicated footnotes files.

Admittedly my footnotes are typically very short, nothing longer than a paragraph[^PAR]. They may contain a LaTeX formula or a Markdown style referernce like [See here](https://see.here/index.html].

[^PAR]: Usually a short paragraph, one or two sentences.

When converting Markdown to PDF the footnotes appear at the bottom of the corresponding page. When converting to ePub they appear at the end of the chapter.

In either case the export tool makes the footnote a link so a click on the footnote sends you to its text. The export tool also places a reverse link at the end of the footnote text to send you back to the reference.

[vkbo]

That seems to be in the context of technical writing, or non-fiction at least. It makes sense to use footnotes there. It's not very common in fiction, but for instance Terry Pratchett does it quite a lot. It would be nice to have the option, and it is, as you say, supported by ePub.

Spreading them around or collecting them in dedicated files makes no difference to the way it would be implemented in the code. I would just have the indexer class collect them like it does for the synopsis. It's mostly an issue of how to indicate that a set of paragraphs belong to a single footnote without relying on indents as in kramdown.

It's not a high priority feature, and I may just leave this Issue here in case there is a request for it.

[alexisargyris]

Most definitely! (BTW, I'm interested in fiction, not technical writing). I just came across novelWriter, went through its currently available features -- and was very impressed! -- and concluded that it's missing one, very important, thing: footnotes (and endnotes)!

[vkbo]

Thanks for your feedback :)

I absolutely see the value in adding footnotes for fiction-writing, so I'll tag this issue for the version 1.1 release since there is interest in it. I'll add it as soon as I'm done with 1.0, maybe before, but if so, it'll be in the dev branch.

[vkbo]

Possible notation for this proposed in #1337.

[vkbo]

Following from #1337, I think the following notation may work:

This is some text with a footnote[footnote:mynote] in it.

[target:mynote] This is the text of my footnote.

[target:mynote] If I wish, I can add a second paragraph to the footnote.

I'm not sure if target is the best keyword for the definition, and I would like to also allow fn as a short form for footnote.

I'm also not sure if I want to distinguish between footnotes and endnotes in the syntax, and instead make it an option in the build tool. How they are treated is somewhat dependent on output format. Footnotes don't make sense on formats without pages. There they become chapter notes or endnotes anyway.

[xahodo]

How about doing it like Latex does?

That would mean [footnote]some text[/footnote] right in the middle of the text where the footnote is needed. NW could then figure out, in accordance to a setting, what the footnote number is.

The reason for defining it in the middle of the text is that the footnote is defined where it's relevant, not at some external location, so things are easier when editing later (i.e. you don't have to reference another document when editing, but the relevant information is right there.

[vkbo]

For short footnotes, that is fine. However, I would like a way to refer to a footnote as well. This is useful if you refer to the same footnote more than once, or want a footnote that is longer, or rendered as an endnote.

So you could have the option to:

1. Write Text bla bla bla[footnote]Foot note text.[/footnote]. More text bla bla.
2. Or, point to a target like Text bla bla bla[footnote=mynote]. More text bla bla.

I think it should be possible to implement both.

[vkbo]

In any case, since you can define the [target] wherever you want, you can easily just put it after the paragraph where you use it. This is cleaner than the inline notation anyway. I don't particularly like the LaTeX approach. It is very messy when writing.

[vkbo]

Looking at the history here, I like @johnblommers suggestion. I will just use a syntax that is more consistent with the shortcodes already implemented.