I am writing a book with many small subsections. When I’m working in Scrivener, I don’t like my binder to have hundreds of documents that only contain a few lines or a few paragraphs each. It’s just hard to keep track of them all, and I don’t like how Scrivener inserts the black lines between documents when viewing multiple documents in the editor. I prefer to combine a whole group of subsections into their own document. That way I don’t have as many documents to manage, it’s easier on the eyes, and when I’m editing I get a better feel for the flow of the document.
However, this has the unfortunate effect of turning all my subsection headings into regular body text when I compile. Is there a way to identify subheadings within a document and tell Scrivener to format them differently than body text when compiling? I want them to be larger and left justified.
Sure, Scrivener doesn’t force you to work any particular way, but it pays to learn how and why it does the things it does. If you haven’t already done so, check out the interactive tutorial, which goes over the various functions of the compiler in Step 16. It sounds to me as though you have chosen a compile preset or template that assumes you’ll be structuring your book in the outliner though. Check the Formatting compile option pane and make sure that override text and notes formatting is disabled.
By the way, if your only grief about outlining more deeply than whole chapters is the black line, you can turn that off in Formatting preference pane at the very bottom. Set the separation to single line breaks.
Amber, thanks for the reply. Since posting I discovered that you can turn off the black lines. You can also display the document names in the editor by going to Format > Options > Show Titles in Scrivenings. That solves most of my issues.
I would still prefer not to have so many tiny documents for just a few lines of text. I’d love to be able to type the subheadings in the text itself. Right now it appears the compiler will format them as body text. If someone can tell me how to do this and have the compiler format them differently from body text, I’m all ears.
Did you try turning off the feature I mentioned in the prior post? The settings you have adopted for your project are assuming that you want the compiler to clean up the formatting of the manuscript to a unified font and look. Thus if you try to do special formatting in the editor it will always be normalised when you compile. There are of course several ways around this, but the one I suggested will be easiest if you already have hundreds of section titles written.
In the future you may wish to learn of the Format/Formatting/Preserve Formatting feature, which lets you mark out bits of text the compile formatter should ignore. You can also fine-tune what sorts of things the compiler even changes in the first place (as well as what Preserve Formatting protects) in the Options button of that pane.
Glad to hear you found an agreeable approach to Scrivenings display.
Yes, I have “Override text and notes formatting” turned off. This has at least seemed to preserve my subheadings’ bold formatting, but not the indentation or size. My body text is 12 point with a first line indent, but I want the headings to be larger (depending on their level in the hierarchy) and left justified. Right now they are being indented and reduced to the same size as the body text.
I have read a bit more about the preserve formatting feature, and it looks like that will do it for me. I only want it to preserve the font size and indent, which I can control from the Compile formatting pane.
I’m not sure which direction I’m going to go now.
Option A: Break up my larger documents into a million tiny ones, delete the subheadings, and add the subheadings into the document titles, then change the scrivenings display to show document titles. The thing I don’t like about this idea is that the document titles are all displayed with the same formatting, which obscures their location in the hierarchy (I use font size to distinguish between levels in my document hierarchy).
Option B: Go through the whole project and mark every subheading with preserved formatting, then change the formatting options in the compiler. This one might work better, but it seems very error prone.
Neither one sounds very appealing. Either way it’ll be a lot of work. Sigh.
Hmm, the result you are describing isn’t the way it should be working, so I wonder if perhaps I’m not fully understanding what your situation is. It still sounds as though formatting is being overriden. Bold, by the way, is never touched by override formatting, nor is italics or other forms of formatting that one might frequently use. If we destroyed that stuff when compiling, I don’t think anyone would ever use this feature. So the fact that they stay bold isn’t really an indicator that it is working right anyway.
In short, if the override formatting feature is turned off, your Formatting compile option pane should grey out the sample text in the block, and nothing should be changing when you compile; indents, font size, font family, absolutely nothing should be changed. Are you in the right tool? We’re talking about using the File/Compile... menu command, clicking the “All Options” tab, and then clicking on the Formatting pane in the list on the left.
A few notes on your options:
The Formatting options in the compiler are specifically designed to allow multi-level formatting. You can have a 24pt centre aligned bold chapter title as a level one folder, but for folders nested in that folder in the outline, you can use an 14pt underscored bold title that is left aligned. So the choice to put titles in the binder names and let the compiler generate titles for you does not mean you are stuck with one format. For a brief demonstration of this, you could select the “Enumerated Outline” compile preset and then examine the Formatting pane. See how there are now six or seven levels of formatting defined, and if you click on different ones you can see they all have different indents and such. Hit “Cancel” when you are done to revert to your old settings.
This is only error prone if you do it manually. Preserve Formatting is something that can be saved into a formatting preset. Try this, type in a fake title in a document, apply Preserve Formatting to it. Now go to Format/Formatting/New Preset from Selection. Give it a name like “Test Subheading” and leave the options default. Now type in another line in your editor, and with the cursor in that line, use the style drop-down in the Format Bar (far left button) and select “Test Subheading”. See how both the formatting options and Preserve Formatting are applied? This is the ideal approach for those that have a lot of special formatting in their work. For example, block quotes are an exceptional use case for this feature.
But again, as I said initially, either of these options at this point would be very labour intensive, and that is why I did not even mention them to begin with. They are definitely something to think about for your next project, but for a completed work, where you’ve already formatted the stuff in the text editor to look the way it should print, just makes sense to not override formatting in the first place.
Whatever the case, we should be able to find a solution for you that doesn’t involve hours of messing around with what you’ve already written!
It looks like I failed to mention that I’m compiling to Kindle format. Sounds like it could be a limitation of Kindle that’s ignoring my heading sizes and making them all the same. I think the indentation issue might have been occurring before I turned off the “override text and notes formatting” because I just tried compiling again, and the indents are looking OK now. So now it’s just a matter of getting the headings the right size.
I was aware of the ability to vary formatting based on the position of the documents in the hierarchy. That would work great for the final output. But I really like to see the headings formatted and in context while I’m editing. Choosing Format > Options > Show Titles in Scrivenings at least gets the document titles into the editor in the right context, but they all look the same.
Headings are more than content—they are a visual reminder of the document structure, too. And that’s really useful to see during the writing and editing process, especially when you have a highly structured and hierarchical document.
I’m glad to hear that Preserve Formatting can be built into formatting presets. That should work great!
The headings are NOT all the same size after compiling. But the difference is small enough that I couldn’t tell until I finally put some right next to each other to check. In my source documents, the two main headings are 18 point and 13 point, and the difference is quite striking in Scrivener’s editor. But when I view the compiled Kindle book on my Kindle, they look like they’re maybe 2 point sizes apart. I can’t even tell unless the headings are right next to each other. It’s not enough to get a visual indication of what heading level you’re looking at.
Oooh, yeah Kindle is another raft of complication. That said you should be getting font size variation (on update, I see you have noticed that). Scrivener does pass that information through to the Kindle. Now, the Kindle can be a little “abstract” when it comes to sizes. It’s not going to print something at exactly 18pt, because the size you specified could be totally inappropriate on an iPhone. It takes a loose interpretation based on relative sizing. Percentages are used to express sizes, not fixed values. This is because the reader ultimately has control over font size, thus all of the text in the book is calculated back from that base size on the Kindle device itself.
The upshot of that is that if the relative size differential between different text samples is not significant it can cause things to end up looking very similar, or even produce weird results you might not expect, such as titles being smaller than the base font size—which is never directly declared. Thus, if the base size is close enough to the subheading size, Scrivener ends up making on a very subtle distinction if any at all.
A good rule of thumb when designing an e-book: don’t try to set the base font size, just leave that normal, and keep your headings sized so that they produce relatively substantial proportions, because that can otherwise have strange side-effects. The Kindle is meant to handle the base size itself (so those with poor vision can increase the whole thing easily, and so that different devices can set appropriate defaults).
Got it, and yes I do agree with you on that. I use titles as well myself and I often wish that they had some kind of distinction as to what level they were coming from. It’s something we have on the list to think about for the next major version. It’s a little complicated because we don’t want to insinuate that the formatting in Scrivenings is related to what things will look like when you compile.
I get so frustrated with Amazon’s Kindle format. I don’t see what they gain by making the conversion process so obscure. It’s like half the time you just cross your fingers and hope it comes out, but they haven’t given us enough information to know. It seems like everything would be better if they were more forthcoming with exactly how their file format works.
I am using the default Scrivener body text for everything, and I worked from there. So I have Optima regular, size 13, for my body text. The smallest heading size is 13 point bold, and so on from there. I would think that the difference between 13 and 18 points is pretty big, but it’s apparently not enough for Kindle. It’s like they reduced my 18 point headings to size 14, maybe 15. If I had been properly segmenting my text into documents and putting headings into the document titles, I could more easily change the heading size. Shoot. I might just have to deal with the headings as they are at this point.
To harp on this a bit more… Sometimes the visual aspect of the text really can inform the writing process in a valuable way. Especially when you’re writing a highly structured, hierarchical document with lots of headings and sections.
Headings can give you valuable information about where you are, both in the document hierarchy and in the overall flow of the text—without having to look outside your text. Besides providing an important sense of context, they can sometimes contain valuable content that informs the text around them. They aren’t always just placeholders.
In short, headings are part of the text, too—with regard to both content and structure.
Are you any good at editing CSS? Because in the KindelGen compile option pane you can choose to export the source files as well as the .mobi. That will create a folder with everything needed to create the e-book, but as source files you can edit with any text editor. You can go in there and fix, normalise and tweak your headings based on the style classes used to draw them. When you’re done, just open the OPF file in Kindle Previewer and it will compile a .mobi for you.
I know a few things about CSS from having fiddled with it before. I might give that a try and see if it’s something that’s within my ability. Thanks for the tip!
