I'd consider myself pretty technical being a 3d generalist and a programmer, but the compile formatting system is....

The compile’s formatting system is undecipherable. It’s so unnecessarily convoluted and complex that it’s almost funny. I find myself resorting to trial and error rather than anything working as intuition would suggest. I actually found it more straightforward to learn CSS and Bootstrap than this unfathomable mess.

I’m using the beta by the way.

I’ve read the manual, I’m sure I’ve understood it, but changing one layout seems to affect other layouts as well. For example, I change the text of the heading layout to have centred text, and the compiled pdf has all text centred even if they’re in a different layout type whose text is still set to left justification in it’s own options.

Perhaps it’s just buggy, not sure. Regardless it’s a total mess. Particularly the seperators options.

Have the pencil icon bring up options specific to that section only, and have the cog icon bring up options that affect the entire document (if not overridden in the layouts).



I think I got used to it (I am primarily on S3 Windows, although I use a Mac version of S3 as well). My experience was trial and error … but my saving grace is that I use something after the compile to actually format / process the final document. But you’re right, it is “complex.”

So, my process is Scrivener → Word (with the compile settings to simply define heading styles.

From there I import it into Kindle Create, which splits it up and does the interior design for the eBook. I have not tried to compile for iBooks / Kobo / BN yet… I’ll probably take the Word Doc to InDesign for POD files.

Good luck.

Well, I’ve got it going now finally, but I have to say it’s the most abysmally designed system I’ve ever had the misfortune of encountering. At several points, I was so aggravated that I actually considered writing a scrivener alternative.

The fundamental problem is that what Compile does is hard. “Take potentially hundreds of files, all of which may have different formatting, normalize them to a single standard, combine into a single file, and output to any of a half-dozen different file formats, all of which may have different requirements. With as little user intervention as possible. For any possible writing project, from a poetry chapbook to a Supreme Court brief.”

To the best of my knowledge, no other software even attempts to do anything similar.


Yes, I agree that catering for a multitude of output formats requires a bit of work under the hood, but that doesn’t affect the UI. The problem with the UI is everything’s mis-mashed together, and options aren’t specific to the UI element whose options button has called them. It also uses terminology for multiple purposes (you have ‘section’ layout types which are named ‘section’ in the pre-configured formats and then the option to place before/between sections which refers to any section layout rather than just those named section),

A better option would be that you can only edit separators for the section layout whose pencil button you’ve pressed to open up it’s options. This would mean no need to manually select the section layout you’re editing in the section layouts section, and the separator tab would have options for just the current section layout rather than the defaults separators and all the other section layouts.

Any options that are not specific to the current section layout should only be accessible from the cog icon in the bottom left of the compile dialog rather than each section layouts pencil icon.

Maybe this is a difference between Windows beta and macOS, but on macOS when you click the “pencil icon” in the “section layouts” panel you are taken to the correct place in the compile format designer ⇨ section layouts (the separators feature is not focussed). Yes, the format designer also allows access to other section layouts, but there is a logic to that.

Your alternative is to separate each section layout into its own closed silo, but this is not IMO flexible if you are trying to design a cohesive compile format, where you want to edit different layouts, along with general features in a consistent UI. Or you could have TWO UIs, the silo-per-layout and a general format designer, but that would be entirely confusing and I image impossible to program without a myriad of corner case bugs and issue.

I think of the pencil icons as shortcuts to the format designer, and this is IMO consistent and efficient (actually I never personally use this icon, but dive straight to the format designer UI). I am sure Scrivener’s UI can be improved (nothing is perfect), but in this case I really don’t think the alternative would improve usability. I find the format designer mostly logical, well designed and a joy to use, but we all have different ways of interacting with software.

If we break this down, we have section layouts and features (separators, styles, transformations etc). Not all features apply to layouts, therefore the logic of siloing by layout is not IMO viable. Scrivener chose to consider section layouts as a feature, and therefore accessible as a panel in the format designer. This is a single cohesive UI.

If Separators were removed from the feature list and added as a setting of the Section Layouts editor itself this would mean you could click the pencil icon and go to the designer focussed on that section layout and the separator would be part of the options there. The major problem with this though is: what about settings for default separators? Separators are an example of a feature that can apply to section layouts but are not exclusive to them…

These are some of the reasons that Scrivener’s compiler is focussed on features, and that settings for layouts are not separated into their own isolated domain. Added onto this, for different formats, different features are necessary, and this only reinforces why the format designer is feature-focussed — because it is the best compromise of design, not just some random mishmash of buttons thrown together without any reason…

The problem is that separators don’t “belong” with section layouts, necessarily.

For example, you might use different section layouts for the Foreword, the Acknowledgements, the chapters in the body text, the Translator’s Notes, and the Bibliography, but you might want all of them to be separated from each other by page breaks. Or you might put a page break before a chapter’s epigraph, and as a result decide you no longer want one before the body text of a chapter.

Separators, by definition, lie at the boundaries between sections, so it’s not appropriate to isolate them as you suggest.


@kewms @nontroppo, I think this is where the confusion is, you seem to be talking about section types, I’m talking about sectin layouts. As far as I can see each section type can only belong to one section layout.

When a section type is assigned to a section layout, I can’t see any need to access the options for the other section layouts or the defaults which apply to all section layouts. Defaults need to be in the format options, section layout options need to be accessed via each section layouts pencil icon.

There’s no need to have both in both places, and the functionality would not be hindered in any way, because all options would still be available. This is a suggestion to simplify the UI whilst maintaining the same functionality.

No, I’m talking about section layouts. It is not unusual for a complicated manuscript to involve multiple layouts, and therefore to require exactly the kind of control over separators that I described in my post. Again separators, by definition, lie at the boundary between layouts.

Scrivener is used for an enormous variety of projects. While you personally may not see a need for a particular function, it is quite likely that some other group of writers finds it essential.


I’m not following then. Why would each section layout having just it’s own options reduce the ability to give each section layout different separator settings?

It would be identical functionality, without the ability to alter the other section layouts unless going into each of their options dialogs individually. Nothing would change apart from the UI. All existing options would still be accessible, just in a more intuitive manner. This reduction of ambiguity caused by the same options being accessible all over the place would also allow for better option terminology because there’d be no need to differentiate between multiple section layouts from within one dialog.

Default options for separators etc would still be accessible from the cog icon (because they’re applicable to the entire format unless overridden in each section layout’s options.

Again, because separators lie at the boundary between potentially distinct layouts, it is not really accurate to define them as "part of " the section layout specification. So I’m not sure how making a distinction between “separators that apply to this layout” and “separators generally” is “more” intuitive than the status quo.


Don’t separators that lay at the boundary between distinct layouts just use the ‘before’ unless overridden in the preceding layouts ‘after’?

Indeed, now a feature has been broken up and is now in two places for the UI, this makes checking inheritance and relationships between the settings for section layouts harder, not easier. Section layouts inherit from their “global” parent, but can be overridden. Currently, this is all laid out in a simple and unified UI pane:

[attachment=0]Screen Shot 2021-01-08 at 07.21.57_SMALL.png[/attachment]

With this, I can easily check check the global parent alongside the child overrides — the relationships are clearly visualised by the UI in one place. If I want to change all text sections to be consistent, this is easily available in the current UI as I can trivially focus each layout and see the same UI settings (without any jumping around) directly. Why silo these into separate areas of UI, breaking this “feature” into scattered settings and requiring jumping out and in of different interfaces? What is so “unintuitive” of thinking of separators as a feature that can be global, but overridden, and those overrides are managed in a central location?

Sendmail.cf and (later) even the m4 macro configuration shortcut for sendmail.cf are still many orders of magnitude more WTF.

I mean, it seems that Scrivener is moving from what it actually was created for “helping you write a first draft” to being that PLUS a desktop publishing tool…which in some ways makes sense. People want to spend less time and money in post…I get that.

But, in doing so, and implementing desktop publishing…less adequately than, say, word, it may have shot itself in the foot…just trying to figure out styles now and, while I was excited it had been implemented, the way it is implemented seems pretty broken IMHO… sigh

Too bad, as this poor design was the only thing that kept me from buying it multiple times over the past five years.

It’s true that Scrivener’s output formatting capabilities have expanded greatly over the years. But calling it a (poor) desktop publishing tool is simply wrong. It is not, and does not claim to be.

Scrivener aspires to be the best tool available for researching, planning, and writing long documents. All the features that support that goal still exist.

With the addition of a true Style system in Scrivener 3, it also seeks to facilitate output to more capable formatting tools by labeling text in a way that those tools understand. If you plan to go directly from Scrivener to a publishable output document, it’s entirely possible – depending on the specific project – that Styles are completely irrelevant and can be ignored.


But it’s not. And L&L have been VERY clear about that. The compiler is there so you can take all of this crazy quilt of documents and material that you’ve assembled (often from other sources), arrange it, and (without having to worry too hard about all of the formatting across your collection of documents) stitch it together into a single, cohesive output document where the inconsistencies have been smoothed out.

That’s how the flow worked for me back when I was still writing technical books and magazine articles (without Scrivener in the picture), BTW. The industry used Word templates, yes, because Word was a de facto standard, but every publisher I worked with had their own template they expected their authors to submit work in. The formatting in the template was there to facilitate making life easier for the editors, and to ensure that things got properly poured into the layout tools (FrameMaker, InDesign, etc.) once all the writing, editing, and revising was done. None of those templates ever bore any resemblance to the final published product.

Scrivener is just taking that “write then layout” philosophy to the next stage. Compile is not a last-mile layout tool, but as a side effect of imposing consistency on the output, it manages to be “good enough” for a lot of the uses people use it for. It supports too many target formats that don’t support those kind of features (ePub, etc.) It’s a testament to their work that many documents don’t need any further layout work in order to be a perfectly usable ebook – but if you do need more precise layout control, that’s when you compile to something like .docx, take the compiled document, and import it into an actual layout tool to perform the rest of the work, consistently, in one place. Or, you figure out how to integrate it with things like LaTeX, Pandoc, etc., to really automate the process.

Indeed. The existence of those templates is one of the reasons why Scrivener 3 has Styles: to facilitate transferring the project from Scrivener to a Word-based editor or layout designer.

And, incidentally, when I was working as an editor, the very first thing I did with any submitted manuscript was to strip out almost all author-supplied formatting.