Glad to hear it’s a functional start.
Building the ToC YAML wouldn’t be too difficult. I could have a look at that if you haven’t figured it out yet, but just building a string in that first loop, as filenames are calculated, should be sufficient. The result of that would then need to be written out to some master file I suppose. I’m not familiar enough with Quarto off the top of my head to know what that looks like.
I don’t know where that hashtag after the index items comes from. It’s probably added by the script, while Quarto only wants the left hashtag for headings.
The script doesn’t touch text, other than to locate split markers and remove them.
That’s a setting you can disable in Scrivener. Previously it would always balance hashes on the left and right of the heading text, and still does when creating a blank new Format, or copying from any of the MultiMarkdown formats. But a release or two ago I did change all of the Pandoc specific formats to only use left side hashes. It’s not that Pandoc cannot handle them, but they can conflict with easily adding attributes to the line, a thing MMD doesn’t have syntax for. For example, ### Heading Title {.work-in-progress}. Quarto does use these, so there might be some bad interaction going on there.
To fix it, edit the compile Format, and in the Section Layouts pane, click the options button in the top-right corner and disable Add closing hashes to titles.
- As written somewhere in this thread, cross-references should be broken, and require manual rebuilding. For long projects, this can be a real pain. Unless I’ve missed a workaround.
Is that actually a problem with Quarto though? Since it encourages this multi-file approach, doesn’t its cross-referencing syntax handle that problem automatically? For example, their syntax is @fig-someimage, which presumably would create something like, <a href="targetfilename.html#fig-someimage">Reference text</a>.
Otherwise, it’s not a massive burden to form your links correctly in the first place—it’s something you’d be doing if you were using Markdown to create a site anyway, the only difference here is that you’re using some automation to go from a single-document output a many-file output rather than working in many files from the start. The main alteration you’d probably want to change is to remove the auto-numbering placeholder from the filename output in the Section Layout that does that, so that your file names can be predictable; “BlackBook.html” instead of “2-BlackBook.html”. Considering how linked placeholders work in Scrivener, you could even keep your syntax agile in the editor, with something like this:
[Refer to <$title>](<$titlenospaces>.html#fig-someimage)
…where both of these placeholders are linked to the file generating level of the outline this figure descends from.
The alternative is to implement CommonMark/Pandoc compatible parsing for anything that might have an anchor generated for it, including Pandoc’s attribute strings, and build an array of that as the script scans the file, then also have parsing for any form of syntax used to create links, so that the calculated filenames can be prefixed to the URLs found within them—and as well avoid damaging any URLs that shouldn’t be prefixed.
That’s quite a lot of work for a little simple script like this! Especially when it can be solved by just doing things correctly to begin with rather than taking shortcuts with the link URL (or using a processing system capable of handling cross-file link resolution). Last I checked, there are no Ruby gems for full-scale Pandoc markdown parsing. Plenty of stuff for integrating with it, wrappers for it and the like, but understandably there isn’t as much of a desire to essentially replace it.
