Oh hmm, I’ve never tried to force document structure using styles like that. As you say, it might be time to give more control over to Pandoc. You get a lot of goodies without much effort, and this is all is a good example of that (with a little help from Memoir, too).
I would only consider switching over to styles for very unusual heading types, that perhaps are not part of the document hierarchy, like “See Also…” lead-ins to lists.
Basically I’d aim for something like this:
\frontmatter
## Acknowledgements
## Prologue
\mainmatter
# Part One
## Chapter One
### Section One
(etc.)
The division declarations for switching matter types are assumed to be coming either from the template or your binder items, as the case may be.
I would emphasise how clean and simple this is. No class spamming, no overrides, just marking down exactly how much you need to convey the book structure and letting the heavy-duty software take over the rest (and of course from your point of view this is all coming from neatly indented lists in the binder with probably largely structure-driven Section Types you don’t even have to think about).
Some of the magic that would be happening here is Pandoc, in converting these hashes to headings of the right depth, but some will be Memoir as well—for example if you check its documentation for what the \frontmatter declaration does, in its section on Logical Divisions, you’ll find it automatically suppresses numbering on headings and uses lowercase Roman numerals, resetting everything but various caption numbering for the main matter.
You really don’t have to do much forcing, in other words, as it has sensible defaults. The main oddity here is using a level two heading for your main matter items, which you need because you’re using level one for parts (and you probably don’t want a full page spread for acknowledgements!).
With Scrivener you could accomplish this by creating a “Front Matter” section type, and then assigning that to a Layout that forces the hash level generation to two, regardless of the item’s depth in the binder, in the Title Options tab.
But a better approach might be to create a “Front Matter” folder (not to be confused with Scrivener’s feature for it) at the top of the draft, for these sections, which would automatically bump the hash level to two anyway, and then for the section layout that handles this container folder, plug the \frontmatter declaration into its Prefix tab, and the \mainmatter into its Suffix tab, with the option to place it after all child items. That would be even cleaner!
So a little setup, either way, but once you have that you can more creatively and freely outline in the Draft without really thinking about these technical details.
Here’s a little demo of that idea, in action, with the resulting PDF in the binder. It probably won’t compile for you without tweaking the command line or switching it off so you get pure .md, but the important stuff is all in the section types and layouts, anyway.
sample_frontmatter_compile.zip (233.4 KB)
You’ll note that by switching over to using hashes for headings instead of styles, you can probably dramatically simplify your section type/layout setup too. Since the compiler is adding hashes based on outline depth, and those map to \part, \chapter and so on automatically, we don’t need to spell out in great detail what we want. Your choices often narrow down to: does this need the concept of a heading, does it need text?
What I’m doing to debug right now is cutting Scrivener out of the loop and just processing a dead-simple markdown file in pandoc. I think that’s the current gap in my knowledge. I’m (over)confident that I’ll get there.
That’s almost always what I do when I’m figuring something out. I can punch UpArrow+Return on the last latexmk -xelatex test command line over and over, get it all right with tweaks to the .tex file, then move on to putting that solution into the Pandoc template or whatever, and once I test that it works good against Markdown source, make Scrivener create that. Working the other way around is very slow, compile is by far the bottleneck, and feels too much like remote control to me.
My end goal is the same: once source Scrivener project that I can ship to many formats without manual monkeying.
And getting the structure more semantic, less style-heavy, is I think going to go a ways toward that, even if it might seem like abstraction might make it more difficult—like I said above, there is a lot of magic that a lot of volunteers over the years have put together to make our lives easier.
As a career nerd, I appreciate having a million command line options and a config file that I can iterate over.
and am much more inclined to leave markers in my text and post-process the resulting TeX file prior to the hand-off to PDF conversion.
The Section Layout can insert that for me, so I don’t really think about it while writing, and the source works equally well for Pandoc.