Right, that may blend the best bits of both. An even simpler alternative is that for sections for which #1-6 level headings are insufficient, you can use custom tags injected into the title suffix or a custom tag prefix at the top of a binder doc (if there is no title) to do the splitting, for example the (&&&) would be parsed to create a folder for the first part and a titleless file (#^notitledoc) for the second, the actual tags are arbitrary, they just need to be unique:
# My title &&&
blah
#^notitledoc
text
This is stuff Scrivener’s compiler can add easily based on binder structure and you can easily regex in squarto when processing the markdown to control how the split occurs. This is easier than reading the XML; though if you already have the XML parsing finished then it may not matter for your use case. I personally find it annoying that Quarto demands multi-file projects for books/websites, it should be able to use either heading levels or files to define output structure to be honest (and it annoys me it enforces reproducing accessory files into the project folder [even if they are symlinks], Pandoc is much more flexible in this regard)…
The new Quarto Manuscript project format is capable of using single .qmd files or multiple .qmd files, as specified in _quarto.yml, and it generates a long-form article based on #H1 - #H6. If you don’t need a true “Book” structure (parts, chapters, appendices, table of contents, index), this might work better for you.
The Quarto Website project format can use single index.qmd files or multiple files, as specified in _quarto.yml. The Quarto Book project format is based on the Website project. As this format is intended for really long projects, it makes sense that it would expect multiple files (essentially, one file per chapter). But I agree with you that this should be more flexible, with an option to use #H1 for parts and #H2 for chapters.
For now, my symlink strategy ± Cookiecutter template approach may be sufficient. For my writing, I link to my entire Zotero library using a symlink to the dynamically generated .bib file. All my references go in Zotero, so a Cookiecutter template including a symlink to that file is sufficient. The .csl file may change based on target journal or publisher, so that part will have to be considered. Maybe the Cookiecutter template includes the option to choose .csl at time of project creation (very easy to do via Cookiecutter).
(It appears that Quarto does accept an internet URL for at least the .csl file – but not a full absolute path on your hard drive.) ↩︎
Wow, y’all. You’ve gone DEEP. I recently completed a scholarly book using Scrivener+pandoc. It had lots of math and cross-references, but only seven tables and three figures. I had thought my personal Scrivener project was highly customized, but now I realize it might as well be made by Playskool, given that I can’t follow one-tenth of this conversation about desirable features for academic writing with markdown.
In my case, the essential things I had to pin down before writing the book were (1) a way to handle and cross-reference equations and chapters/sections, and (2) a universal way to designate when text after an equation or block quote should not be indented. By “universal” I mean a procedure that works whether or not one is outputting to pdf/tex or docx. @AmberV helped me figure out best practices for both, and I’m really happy with the resulting setup.
Carrying over one more comment from the other thread (focused on Squarto)…
My experiments with Squarto have helped me clarify what the Scrivener 4 Compiler would have to do:
The Compiler should have a “DAG” (directed acyclic graph) interface that basically allows you to specify a pipeline or workflow for each element in the Binder: step 1 → step 2 → step 3 → etc. So instead of the Compiler going from “top to bottom” (simply aggregating the text documents in the Binder), it should allow specification of processing of each text document separately. Some of these text documents may then get aggregated with ones below it, but some of them may be totally separate things (for example, being saved as separate files).
On that note, the Compiler should allow saving files stored in the Binder to a specific directory.
Don’t limit frontmatter and backmatter to one element in the Binder – rather, allow Compiling anything in the Binder, even if outside of DraftFolder;
Facilitate specification (via a settings pane) of the location of paths to Pandoc, Quarto, .csl and .bib files, etc., and maybe even a preferred virtual environment.
Allow running pre-processing and post-processing scripts in a full shell that respects paths and virtual environments.
The first bullet point (DAG interface) would be the biggest change. The others are tweaks on Scrivener’s existing compiler.
Hi. Yes, we’re in deep But it’s not as complicated as one might think once you get used to it.
An experience similar to yours is what drove me to seek out Quarto (so a Scrivener → Quarto → Pandoc workflow, rather than just doing the Scrivener → Pandoc workflow). Quarto greatly simplifies cross-references of figures, tables, equations, other chapters/sections. It also allows mixing of Markdown, LaTeX and HTML/CSS in interesting ways, let alone incorporation of executable code. But I’m sure that Quarto is overkill for many people!
I’m curious about this problem and the solution that you reached. Would you mind linking to your original post on the topic?
The compiler already can do this, in that you can choose which items get compiled or not, and for each item we can use Section Types to specify the processing in more detail. This is granular to the level of individual items in the binder.
I have a slightly different perspective on the steps and ordering, in that the compiler does perform multiple steps (convert styles, do regex replacements, transform placeholders etc), and the order does impact setup and an option to specify order would be helpful, but this would also add additional complexity for only marginal benefit…
Right, at present Scrivener is “monolithic”, ultimately whatever is selected ends up as one document. I really doubt this is going to change, and there are many complications to existing functionality (links / cross refs and other placeholders etc.) when partially splitting out sections, this seems a hard nut to crack… But again, many of us use a splitter script without issue. In fact, Pandoc is close to handling this natively too (it already does this for EPUB/HTML, resolving links across files and unified TOC etc.). So I question whether this is necessary, given it is only Quarto that benefits from file-per-section setup?
Already working for me, I always have my YAML metadata outside the draft but gets added to the start of the doc via front matter. Can be multiple items from a folder too IIRC.
Right, this could be much improved with minimal additionaldevelopment. We do have an environment field already to add paths for tools like pandoc / quarto / latex / typst etc. but it is a bit clunky. To be honest all we need is Scrivener to use the user’s shell session, where we can use .zshrc or other shell config to set this up. Virtual environments are a very Python thing, and there are various different tools so I doubt it makes much sense to support these explicitly, they can be triggered by a shell script if needed?
But it’s not as complicated as one might think once you get used to it.