I’m using Scrivener for Windows 1.0.3. I wrote a novel that has been imported into Scrivener. It will be in both an eBook and a paperback. The dimensions will be 5.5 x 8.5 inches. Here’s my problem.
I think I’ve figured out how to set dimensions in the compile function. But I can’t get the editor to duplicate those dimensions. It seems to always assume 8.5 x 11. So, until I compile I can’t see what is happening in the body of the novel. I set up unique margins for description/action and dialogue, so this poses a real challenge. How do I set up the editor for the dimensions I want? Thanks!
This is sort of like the questions that I asked a few days ago ( **EDIT ) so I’d like to know what others reply with Jon M. I’m trying to revert the ruler length and the margins back to the default on all the text files I have under one binder but I don’t know where it can be done.
**EDIT: Other post deleted and linked removed from this post.
Hi - I just wanted to give this a bump because I’m going to be doing major edits on my manuscript soon and I wanted to solve this problem before then. If anyone has any ideas for us we’d greatly appreciate it.
Jon, have you had a go through the main interactive tutorial yet? If not, it would probably be a wise use of time as it will familiarise you with the program interface and some of its core concepts—such as the fact that the compile settings do not at this time have anything to do with how the editor looks. The compiler is more like a document generation tool, which uses the text you feed it in your outline. Text, in this case can even mean that large amounts of its formatting are cleaned up and redone, so it would be good to understand how that can happen as it sounds like you are doing custom formatting while you write. You’ll want to know how to pass formatting through the compiler, and the tutorial does address that topic.
WriterNYC, if you’re wanting to reset the application’s settings to default, there is a button at the bottom, in the Tools/Options panel for doing a factory reset. If you were looking to conform some documents in your project to the current formatting defaults, then use Documents/Convert/Formatting to Default Text Style, on a selection of one or more documents.
Thanks for the help. I tried your suggestions and it still adjust the page width. It’s not a big deal to me for composing in Scrivener, what I’m concerned about is what happens when I compile into a different format? Will the Scrivener page dimensions screw up the formatting when compiled?
I’m not sure what you mean by page width, perhaps that is where I am confused. There isn’t a setting in Options or in the editor that controls or adjust the page. The only thing I can think of that you might mean is the right indent tool. Basically the little arrow on the Ruler that if you drag it left-ward causes text to indent off of the right side.
If that is what you mean, you can reset that to off by dragging the slider all the way to the right. Then text should flow freely with the window width no matter how wide you make it. Generally speaking, that’s what you want in Scrivener. Rarely would you want to block right-indent huge portions of text. In fact that typesetting technique is not often used much. So try dragging the right up-arrow symbol on the ruler, in the Editor settings, all the way to the right until you can’t move it any further. Then select some documents and reset them to the defaults and see if they now wrap to the window.
WriterNYC, the editor is not displaying a ‘page’. It is literally just the area of your computer screen it takes up. Margins and indentation settings therefore will not behave as in a WYSIWYG editor which mixes page layout with writing environment. In Scrivener, they let you create the digital writing environment of your preference, without affecting compile settings.
For compiled documents of any format, in the compile dialogue you can choose a page dimension and generate formatting as you please.
Yes, it is best to think of the editor not as holding pages of text, but rather holding text which will later on be compiled into pages, when compiling to formats that utilise such concepts as pages. That is when things like paper size and margins are utilised in the framing of the raw text you have provided the compile tool.
You can exert however much control you wish to over the innate formatting of the text as your wrote it in the editor. You can leave it so that all of what you typed in, all of your indents etc, or compiled. Or you can have the compiler change those for you to a consistent look and feel depending on what you need to compile for (agent/yourself/etc), but there are no tools in the editor for paper or margin settings; the only place that can come from is the compiler in the Page Settings option pane.
Yes, I went through the tutorial before importing into Scrivener. When I compile and set page dimensions, etc it ends up looking much different than when the text is in the editor. For example, my indents on dialogue lines are not lining up in the same way as when it’s in the editor. Some single lines in the editor become multiple lines in the compiler and fall out of the desired format. I think this happens because the editor assumes 8.5x11, and I’m compling into 5.5x8.5. But I’m not sure if that’s it.
I set margins at 1" (left), 0.5" (right), not just in the editor, but also in the compiler. I’ve tried it with both right alignment and justify. I’ve done word searches in the manual and read those sections that address margin and page size issues. The problem I seem to have is that I can’t do trial and error to learn how to fix the issue for my particular problem because the compiler locks in the text and I can’t edit at that point. So I’m just wondering if there is more of a general fix for this type of thing. I hope that makes sense. I also hope there’s a way to resolve this. I like this program alot! Thanks1
The editor doesn’t assume anything about page size; it is wholly ignorant of it. While the prior three messages were addressed to WriterNYC, this is explained above. There is no paper size in the editor. There are no pages in the editor. There are no margins in the editor. These things do not exist, and nothing in the editor is even indirectly aware of such constructs. There is only text in the editor, text and localised formatting. So when you say you are setting margins in the editor, I don’t know what you mean—but suspect you mean (as from above) that you are moving the indent markers around. These aren’t margins, but only change at what point a paragraph flows on the page. They can in fact conflict with margins after exporting if you set them to large. So absolutely, if you’ve got a 8.5" right-indent then that will make a huge mess of things if you try to fit that into a 5.5" piece of paper. It will flow text right off the side of the page in most word processors that you open the file in. You’re actually specifying a 9.5" right-indent, since you are pushing over the base editor ruler by 1" with the left margin.
Again, it sounds to me as though you are doing a lot of primary design in the editor. You have a specific formatting guideline you need to write to with precise indents for only some types of things and not others. This is okay, you can use Scrivener this way, but you need to disable some of the defaults which presume you are not bothering with indents and just writing pure text. Make sure the Formatting compile option pane has “Override text and notes formatting” disabled. If you work this way you need to be very careful about your editor formatting because that is what will be output. Fortunately most people are used to having things this way thanks to WYSIWYG word processors, so it shouldn’t be unfamiliar.
Just be aware that right-indent needs to compensate for any left margin you intend. So if you are wanting to bring the right side of a paragraph inward from the standard right margin block (for dialogue or what have you), then you need to calculate +1" (for a 1" left margin of course). With a 5.5 wide sheet that has 1 & .5 for margins that means your text block is 4" wide, which means that the right indent marker should never be higher than 4" in the Scrivener editor (what would be 5" in most word processors which also display the margin). It should by default be off entirely, but when it is necessary to use it, if you want to have a portion of text that is narrower than the standard page width, then just remember the +1 rule. A setting of 3.5" in Scrivener will be 4.5" upon output, which would of course bring the text in 0.5" from the normal right-edge which is at 5".
Another way of thinking of this is like a plain-text editor. Imagine writing your book in Notepad. You write every single word without a shred of formatting. Just text. Now when it comes time to put it together to publish, you take all of the text you’ve written in Notepad and copy and paste it into Word.
Now, at that point the text is fit into constructs like Pages and are limited in width by things like Margins, and so on. Prior to that point is just a bunch of letters in a .txt file. Okay, Scrivener isn’t quite so bad as that. It’s not like Notepad where there are no formatting tools at all. You have a good many, but the basic concept of what is happening is very much like that in analogy. When you compile, that is like copying and pasting a bunch of text files into Word and finally formatting them for print. Until you compile, there is no spoon.
Apologies for the Mac word processor, I don’t have a Windows word processor installed on this virtual machine, but the principle is identical. Now the two indent markers in Scrivener pulling the special paragraph in so that it has a total 3" width, or a total of 1" less than a standard paragraph on a 5.5" page with a 1/.5" margin layout. Note also the green rectangle at the top; you can’t see it well, but that is a normal paragraph in Scrivener. That is what almost every paragraph in Scrivener should look like unless it is special and needs to be pulled in on the right side.
Note how this ends up looking normal once compiled and opened in a word processor. See how the indent settings in Scrivener are in addition to the page margins? See how the unwrapped paragraphs now flow into the page size?
Apologies for the confusion. I’m saying page width when I should really be talking about the indents but I think I’m understanding better now. But just to make sure, let me elaborate and ask a few more quick questions:
Firstly, I’m using Scrivener for rewriting and editing my manuscript—obviously .
After I’m done with my manuscript I’m compiling it into an ebook in both the Kindle and ePub format.
When I compile, I want the beginning sentences of each paragraph indented like a typical book at 0.5 inches so since the actual editor does not reflect the indentations I have as I’m composing, I change it to the indent settings I want as follows: File > Compile > Formatting > Choose Level > Click Modify button > then adjust indents to what I desire. Correct?
Then I want all the italics, bolding, underlining, line breaks, centered text, etc that I do inside my document, inside the editor, to transfer over to the Kindle and the ePub documents that I compile. So to ensure this, I unchecked “Override text and notes formatting” under File > Compile > Formatting. Correct?
Now however, by unchecking “Override text and notes formatting” under File > Compile > Formatting will that interfere with the above indent formatting I did under File > Compile > Formatting > Choose Level > Click Modify button, and then instead it will reflect the indents that did inside my document, inside the editor? What I’m getting from your responses is no because the indents that we use when we’re in the editor is only for ourselves as we type and not for the finished product. Correct?
I’ve been testing a compiled Kindle ebook in my Kindle desktop app and it seems to be working the way I’m trying to achieve.
Thank you all a million times over for your help and incredible patience!
I’m simply trying to communicate to you that I am making every reasonable effort to figure this out before bothering you. If you will enter the editor, where you can enter text, then go to File > Page Setup - you will find a Margins area in the lower right corner of that pop up box. You can edit the margins in there. If it doesn’t do anything in the editor, then it should be greyed out to prevent this type of confusion.
I also enter margin settings in the compiler. I have read every area of the manual that explains page setup, margins, page size, etc. So I feel I have at least a decent understanding of some of the unique features.
I would never set an indent that large - that’s ridiculous! I’m not even setting right indents. My indents are on the left for beginning a new paragraph and for dialogue. Dialogue is indented a bit further than paragraphs. I do this to acheive a scripted style. However, in dialogue that is more than one line - the second, third, etc lines go back to the margin edge when the PDF is created, like a paragraph would be written. However, I need them to follow the same indent as the dialogue line above it. This creates a uniqueness to the dialogue that tells the reader, “hey, you’re still reading dialogue”. How is this done without needing to set individual indents for literally hundreds of lines? I have no problem doing this manually…it’s what I would expect. But because I can’t anticipate how Scrivener is going to ultimately format before it’s in a PDF, that seems impossible. Which brings me to my next concern.
Yes, I see that. Do you see how the lines in the editor don’t match exactly the lines in the PDF? Look closely at the first line of the special indented paragraph. The last word of the first line in the editor is carried over and becomes the first word of the second line in the PDF. This is workable when you’re dealing with lengthy text that is all indented the same. However, when there are many shorter lines of text scattered throughout the document, it’s a real problem to set all of those individual indents. It’s essentially impossible without a work around.
Just to avoid any confusion. Imagine a 200 page document with an average of 2 of these types of dialogue lines each. That’s 400 special indents. And, if each of these has an average of 2 lines, now we’re at 800 special indents. Now, you need to create a PDF just to determine where the problems exist. Then you need to go back and forth between the editor and the PDF to fix the problems. Then you need to create another PDF to determine if the fixes changed the document and that perhaps now the fixes need to be fixed. Perplexing! Please tell me there’s a work around to this…thanks!
WriterNYC: Okay, that’s fine! Hence the long descriptions because sometimes terms can be used differently in various software. You’ve noted what is a bit of a Catch-22 in the current compile implementation: you can have it clean up formatting for you, but if you do that, there isn’t a good way to do any kind of special formatting like centre justification or block quotes. This is something that we will be gradually improving over time by providing compile options that let you selectively choose what types of things get left to the editor, as well as giving you a tool that can block out parts of your manuscript and tell the compiler to leave the formatting alone within them. So eventually we’ll have a better way of handling this. For now, if you need special formatting in the manuscript, you need to use the editor verbatim. The formatting you see there should be the formatting you want in the output.
Your job here is slightly easier due to working with e-books, which just by their nature ignore some stuff like fonts. Most, anyway, don’t have very many fonts at all and what fonts they do have are often something the reader selects as a global preference for what they wish to see on the screen.
So to get indents in your e-book, you’ll need to get those into the editor, and the easiest way to do this will be to make sure your default application settings have them in Tools/Options, Editor tab, and then use the [b]Documents/Convert/Formatting to Default Text Style[/b] command to bulk update your files in the draft. Note the options to preserve certain types of formatting—you probably want to enable some of these, at least “Preserve alignment” since you mentioned centred text. The other stuff you mentioned is all good. Italics, bold, paragraph breaks—all of that stuff will be safe. And to be clear that kind of stuff isn’t ever replaced by the compiler anyway in the Formatting pane. It just concerns itself with paragraph and font settings. So long as the font can display bold and italics, you can do that kind of “inline” formatting without fear of the compiler overriding it when that option is turned on. This is only a problem right now with the alignment issue, from what it sounds like.
Just out of curiosity though, are you using the alignment for titles in the editor? If so you could set that up in the Formatting pane to use binder item names for the titles and format them correctly there instead of in the editor. If that’s all you need centre for, you could go with override formatting. If you are using it for epigraphs and whatnot, then yeah, you’re stuck with manual formatting.
When override formatting is turned on in the compiler: yes. Like I said, the compiler will honour inline formatting like italics and such, but when override is on, the output will look and feel much like the sample text. This isn’t a precise science with e-books, but it’s a rule of thumb that works decently well.
⠂─────── ⟢⟡⟣ ─────── ⠂
Jon M.: I apologise if some of this is stuff you already know. As I was saying above, some of these terms have fuzzy definitions and are used differently by software and people, so I’m trying to “calibrate” with what you are expecting and referring to so that I can best give you advice.
All right, the confusion here is that this isn’t something that impacts the editor. In fact it only right now impacts when you press Ctrl-P or use [b]File/Print[/b] to print off a single section for proofing. That’s all it does, and it doesn’t even impact the compile formatting, as you noted. Since these two features (basic printing and compiling) serve such differing purposes, their settings are not hinged together. Since some people do want them hinged, we will be modifying that in the future so that in compile you can choose between the project’s print settings or custom compile settings.
Okay, so that’s the way to think of it: these are project print settings, not specific to the editor. The editor isn’t actually 8.5x11 just because that box says so. They will be printed that way if you use Ctrl-P, but that’s it. That might seem like splitting hairs, calling it not a part of the editor, but I do stress the division between input and output in Scrivener since the two can easily be very different and I feel it is better to frame things in such a way so that one can know that when they use normal Print it probably won’t look anything like Print when compiling, even though the source text is the same. It may, but it probably won’t.
I don’t quite agree with you in that it should be greyed out when the text editor is in use, because while it doesn’t impact the editor (as a writing space), I can’t think of a better time when one would wish to alter those settings. If you wish to go about printing off a section to proof with pen and paper, you’d most likely be looking at the section you want to print. When you press Ctrl-P you have to be looking at that section to print it. So making the user go to the corkboard or something temporarily so they can change the print settings seems to be even less intuitive.
Great! Keep in mind that I only had your description to go by, and not understanding that you were referring to the File/Page Setup bit, wasn’t sure how you were coming to the conclusion that your editor had a paper size and margins. Other people have been confused on this point before and have used the indent markers thinking they were page margins—so it seemed a logical thing to suggest, again in this attempt to calibrate. Since we cannot dump out our entire brains to one another, we must dance around terminology until we arrive at a mutual understanding, which I think we have done now. Thanks for your patience.
I think I follow (though I’ll need a little clarification on your final point below). As I see it you’re basically looking for what non-fiction writers would recognise as a block quote? Basically the whole paragraph’s left edge is shifted over a half inch or so.
If you read the above bit to WriterNYC, you’ll probably discover that there is, at this moment, not a really good way of doing this in the compiler without resorting to just using the editor in a more WYSIWYG fashion. Which I should stress, is totally fine. It’s extremely nice to be able to tell the compiler to use Times New Roman instead of whatever your favourite font is, if you don’t like staring at it, that’s the big advantage. But right now you can’t do that kind of conversion without blowing away your special indents for dialogues, regrettably. If you have override formatting turned on in the compiler, these indents will get blown away, so turn that off if it is on.
The example screenshot I posted was using a verbatim output through the compiler to achieve the final look. Fonts and everything the same (+1 ruler shift aside—which, actually now that I look at that word processor again, I see it is unorthodox and starts 0” at the text block instead of the paper edge—but in Word it would be shifted).
Try ruler copy and paste. [b]Format/Text/Copy Ruler[/b] ([b]Ctrl-Alt-7[/b]) and Paste Ruler ([b]Ctrl-Alt-8[/b]) will make it easy to transfer dialogue indenting from one spot to another. If you just keep that format loaded you can, as you write, periodically use [b]Ctrl-Alt-8[/b] to set the paragraph to dialogue. You will need to recopy each time you start a new writing session as that clipboard is temporary, but it should stick for the entire session so long as you don’t copy anything else.
And by the way, formatting presets are on the slate already for development. Once we have those, you’ll have a handy menu you can use to apply formatting, more like a normal word processor. I imagine that’s similar to what you are already used to from other programs.
One other possibility is using the scriptwriting engine to basically make it so your editor has a “prose mode” and a “dialogue” mode. This is handy, but it also has some compromises as the scripting engine takes up the footer; you’d lose the word and character count stats at the bottom. Let me know if that option intrigues you and you want help with setting it up. It’s kind of complicated to set up for wholly custom environments like this, but you’ll find it documented in the chapter on scriptwriting.
How are you indenting line two, by hand? Try using the two left indent controls on the ruler for the dialogue paragraph, dragging them both to the same position. The top one impacts first-line indent, the bottom one impacts the rest of the paragraph, so if they are both set to 0.5” then both lines of dialogue will start at the same .5 spot, and should flow naturally. That is, if you add a word in the first line which would cause that line to flow over into the second line, it will wrap naturally in accordance with the block indent. You shouldn’t have to be resetting any lines or applying an indent to each and every line.
So, that’s 400 settings as I see it, and again if you just keep those settings in your ruler clipboard, it’s a single hotkey away every time you need it.
I’m lost again with this. I don’t understand why you would need to proof the formatting with such precision and then fix line twos back and forth, over and over, unless you are manually breaking line one where it would wrap and then indenting the second line independently (what I referred to as “by hand” above). I might still not be following and assuming you mean basically a block quote format, when you mean something else.
Or to put it another way, as my screenshot demonstrates, the lines do wrap naturally. I didn’t touch anything in the word processor output, that’s just how it opened with one word displaced from how it appeared in the editor. That style of block formatting allows for automatically wrapping words like that. From your description, it sounds like whatever you are doing would require you to go back and trial-and-error that second word back into the correct line/spot. You shouldn’t have to do that! Unless you are doing something I’m just not following at all.
Okay, I reverted it back to the defaults using Documents > Convert > Formatting to Default Text Style. When I open Tools > Options > Editor tab it says that the margins are as follows: 0” on the left, 0.5” for indents, then 6.88” on the right. Is this the correct default?
And yes, I’m using the center alignment for titles instead of doing it under compile, which I want. However, there’s also other short bits of text that will be centered aligned so I do have to do it manually, which I don’t mind.
One thing else to note, my ruler in the editor still has varied tick marks on the different text files under the same draft binder, but like you said, that won’t be compiled, that’s just for me visually as I’m typing. This makes more sense to me when I go into full screen mode and I see that the ruler changes to fit within the minimal editor. Is that a good way of understanding what you were explaining earlier?
It’s just confusing when some things need to be done in the editor while others in compile or options but I think I’ve got my major problems solved. Does it sound like I’m getting it now?
That sounds right. It’s not actually 6.88", it’s actually turned off, it just appears to be 6.88" when it is off. In a wider editor than this small embedded one, it will appear to be at a larger position. It just basically sticks to the right of the ruler no matter how wide the window is, normally.
But it sounds like you’ve only done the first part of this. These preferences will not blow away the formatting in all of the files you’ve made in Scrivener without your permission. That would be a destructive assumption to make. You have to tell Scrivener you want your files to be updated to the new formatting. From above:
Until you do that, yes, ruler markings may very well drift all over the place depending on whether you pasted stuff in from one application or another, or changed your Editor options at any point in the past and started impacting new files differently.
Relevant to this, there are two ways to compile: one would toss out all of your editor formatting (inline stuff like italics aside) and replace it with a unified look and feel. The other method just uses the formatting in your editor. So no, if you are using centre aligned bits of text then you need the latter method, and that means the ruler variations will be in the word processor in the end. No different than working in a word processor at that point, in this regard.
Well it’s more of a choice, than a need. If you want to handle formatting, you choose to do it all in the editor. If you don’t want to bother with making things look right in the editor, then you can choose to use the compiler to format the document.
Okay, I think I figured out my problem and it’s quite idiotic on my part .
I have a draft binder with about 16 separate text files in it representing my manuscript. The first few pages are book front matter with a short amount of text. Therefore, all the text in the editor is visible right on screen without any scrolling needed to move down the text. In this case, the ruler goes on across editor and to the end of my screen. Then my other text files have an extensive amount of text. Therefore, a scrollbar appears to navigate down all the way to the bottom of my text or wherever. In this case, the ruler stops at where the scrollbar starts.
So I’m guessing this wouldn’t have any impact on the file I compile? Could you perhaps elaborate a bit more on how the ruler and scroll bar works and adjusts to short and long amounts of text?
Yes, that’s quite all right. The ruler has to fit into the space it has been given and the scrollbar takes up a little more space so it pushes it over a bit, and that explains what you mean about it changing in full screen mode as well. It will be shorter there. This is okay, the only thing that is really important are the little symbols on the ruler, that define where the indent is and any tab stops if you are using those. They should always be the same…they might shift a bit from view to view, but as long as the underlying number is the same, you’re okay.
Exception being the right indent (the up-pointing triangle marker all the way on the right side of the ruler), which as Ioa explained above will always just stick to the rightmost part of the ruler–whatever number is visible there depending on the length allotted to the ruler in the view you’re using–when it is “off”, i.e. when it’s not set and text will consequently just go to the edge of the space and wrap. The only time that one needs to stick to a specific number is if you have deliberately set it to create a text block with the right side indented, which is fairly unusual and tends to mostly just be for script formats or occasionally some academic formats–I doubt you’d have that ever in your novel.
I’ve determined that, for my project, I need to compile in the 8.5x11 page size. I’ve been trying to compile in the A5 page size, but Scrivener seems to assume 8.5x11 in the editor. I know that’s contrary to what has been said here, however, in any other page size (other than 8.5x11) it’s virtually impossible to deterimine where line breaks occur for special formatting situations. The result being that the formatting in the PDF after compiling looks altogether different than the formatting in the editor prior to compiling. Perhaps this is something that can be addressed in a future release. Thanks for all your input and help!
Okay, makes much more sense now! After I reverted back to the default settings the way AmberV explained, the up pointing right tick mark on the ruler is adjusting with what is the furthest point on the right side of the ruler as you explained.
So everything seems to be going good now.
Appreciate all the help and thanks Jon M. for letting me ask a bunch of questions under your thread.
.