What I am trying to explain is that Standalone File is the top-most level element. It is above a Part. Just like you won’t nest a Part inside a Part; or a Part inside a Chapter, you shouldn’t nest a Standalone File inside a Standalone File. (Hence the Standalone part).
With Quarto, you can create a book out of a single [q]markdown file, which would be a Quarto HTML Book. (You can also create a book out of several files as well, but let us leave that aside for the moment). Or, you can create a Website, with an index page, and several linked pages. For these pages to appear, you have to add them to the sidebar, navbar or to the chapters parameter, so that Quarto knows which files to add. You can also add the instruction in a way that all md or qmd files would be added (just check Quarto’s documentation).
If you want to see something appear in the export right now, just change the name of one of the files (or the main exported file) to index.md. Then you’ll see the contents of this file on the main page. To see the other, add the Filepath to the appropriate parameters on the frontmatter.
But, having said that, nothing in what you said so far suggests the need to split the text into parts in this fashion, and this severely complicates things. (Perhaps you have specific demands and needs that were not brought up).
So I’ve got this working for my own project, an academic monograph. I have a few citation problems to deal with (separate thread), and one problem with the chapter-splitting script, but overall it’s amazing.
The problem I have with the split.rb script is that it seems to move a lot of the footnotes to the wrong file, and I can’t figure out why. Any suggestions on what I should be looking out for in the source markdown file? Or could I send you the whole file for you to try out?
If you don’t mind sending the whole thing, I would gladly take a look to see if I can find the cause of the issue. Indeed, the script has to change the format of the footnotes from endnotes to inline footnotes, this way they will always end up in the correct file after the splitting takes place. Maybe this is failing for some reason.
Thanks @bernardo_vasconcelos for looking at this for me. With help from the pandoc-discuss list, I have found that the following command line works for my footnotes:
And I’ve now removed the footnote-shifting function calls from the Ruby script. A nice little additional feature of this way of adjusting the footnotes is that it copes with multi-paragraph footnotes, as it just shifts the footnote(s) to immediately follow the paragraph in which the footnote reference occurs.
Thanks for reporting back, @lyndondrake! I will most certainly look into this Pandoc flag and maybe add it to ScrivQ in place of the footnote transfer function.
One thing I really like about my personal Scrivener+Pandoc setup is that I can choose which output I want–pdf, tex, docx–and it will output a file that respects my preferences concerning whether a line after an equation or blockquote should be indented or not. With pdf/tex you can use the \noindent command, but for docx that doesn’t work. So I created a new document type called noindent which I assign as desired. Then I have Scrivener set up to apply \noindent when the output is pdf or tex, or else, if the output is docx, it applies a fenced div that tells pandoc to designate the desired unindented text a specific style in a docx reference doc.
Anyway, this setup works great and I’m happy with it. But in using Quarto via rStudio lately—which I really love—I was trying to figure out how to achieve the same flexibility so I could go back and forth between pdf and docx output. Well, if it helps anyone, I found the answer. It’s the complex-paragraphs lua filter here. It works great straight from rStudio, or you can just run it with Pandoc. It is much easier to get up and running with than establishing a setup like the one of my own that I described above.
Just thought I’d mention it, because handling non-indented text after an equation or blockquote was a big issue for me when I wanted the flexibility of outputting to pdf/tex and docx from the same master markdown text.