Configuring Footnotes for Print

segdae22's Avatar


29 May, 2017 05:47 PM

I know this topic has been brought up in the past but I wanted to weigh in on the issue of print export of footnotes and having them render on the page where the footnote is referenced rather than at the end of the document. I'm not familiar with exactly how your app is coded and taking in the structure of the markdown but there seem to be a couple of options for handling the print export of these:

When processing the markdown, looking for anything with class "footnoteRef" and using it's href attribute, find it's related li element in the "footnotes" div. Create a copy of this div and embed it in its own hidden div immediately after the a.footnoteRef. This would make it invisible during screen renderings but you could then use that to ensure the content is output on the same page during export (again, I'm not sure how you are rendering your output but I would think you could do a page-break-after::before and potentially output the content of these hidden divs using that but without knowing exactly how you intake and output the file, I'm not sure).

Another option could be by providing multiple processors in the advanced screen. I use Marked in conjunction with Pandoc and Scrivener. I know that pandoc can correctly output footnotes if I tell it to export to .docx. The processors section in Marked 2 preferences could be tweak to allow it to override the standard export using webkit-print. This might solve the problem as well.

Anyways, I wanted to make the suggestion. I absolutely love this app and my only beef is that it doesn't properly render footnotes. I'm using it to write my PhD dissertation so when I have to manually go through and clean up every footnote, it becomes quite cumbersome. I'm not sure if any of these suggestions will be feasible but I thought a different approach might get the creative juices flowing so to speak.

  1. Support Staff 1 Posted by Brett on 30 May, 2017 04:35 PM

    Brett's Avatar

    As stated before, all of the fancy DOM manipulation in the world won't
    bypass the issue that an application using the WebKit print system has
    no idea where the page breaks will be prior to the print rendering.
    Inserting footers requires knowledge of the current page height and the
    size needed for the footer, and those can't be modified on a
    page-by-page basis during printing.

    The solution is going to be a rewrite of the RTF export, which is in the
    works. This will allow output closer to Pandoc's, and also be a step
    toward a PDF generator that doesn't rely on webkit.

    You can use any processor you want within Marked (via Custom
    Processors), but it doesn't apply to export. The best solution for
    something like that would be to use a script that `tee`s the output
    but then you're generating a new doc file on every update, which might
    be annoying, and also would preclude any of Marked's other features.


Reply to this discussion

Internal reply

Formatting help / Preview (switch to plain text) No formatting (switch to Markdown)

Attaching KB article:


Attached Files

You can attach files up to 10MB

If you don't have an account yet, we need to confirm you're human and not a machine trying to post spam.

Keyboard shortcuts


? Show this help
ESC Blurs the current field

Comment Form

r Focus the comment reply box
^ + ↩ Submit the comment

You can use Command ⌘ instead of Control ^ on Mac