Configuring Footnotes for Print
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.
Keyboard shortcuts
Generic
| ? | 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
Support Staff 1 Posted by Brett on 30 May, 2017 04:35 PM
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
(http://brettterpstra.com/2014/07/22/custom-export-options-for-marked-2/),
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.
-Brett