Is there a way to set the ruler (indents, etc.) to be the same for a whole document? I can’t get Format>Text>Ruler to work for a whole manuscript.
You should just be able to select all with Cmd-A and then the ruler settings will impact the entire document. However, if by “document” you mean the text within every folder and file in the draft (manuscipt, it might be called if you started with a template), then it’s easier to just set up your preferred formatting in the Formatting preferences tab, and then use Documents/Convert/Formatting to Default Text Style on a batch selection. That’ll also impact new text files you create, so it should be the way you want from the start, going forward.
Amber V,
Thanks much for your reply. Your instruction is what I thought from the manual, but I must be doing something wrong. I set my preferences as shown . I set preferences after I had the manuscript in place. Setting the preferences had no effect. I experimented with the ‘override text formatting for this project’ button. Again, no effect.
I tried creating the indents I wanted (in the first paragraph of the attached sample), then copying them (^cmd C) and pasting them over just this first chapter. No result. In the attached sample, my cursor was in the second paragraph, so the ruler shows the unchanged indents.
Probably a simple matter, but I’m flummoxed
Thanks for your help
The preferences I’m referring to actually in the main application preferences (Cmd-,) not the project text settings. You can do it there as well, but typically you’d only use that for cases where one project needs to deviate from your typical norm. For instance I use project text settings when writing tutorials, because that needs to be presentable, and I myself prefer to write using fixed width fonts, as it appears you do as well.
And again, to be clear this setting only impacts new documents you create. It does not destructively wipe out formatting in files that already exist. To do that you must use that menu command I referenced earlier.
Okay that all said, it sounds like you have something odd going on with your file. Were these written in Scrivener, or were they pasted in from another word processor? I’ve sometimes seen cases where formatting can get stuck if it comes in from certain external sources. It’s rare, but it can happen. Something you could try is selecting all of the text and copying it. Then create a new document alongside the old one, and use Edit/Paste and Match Style. This will strip out all formatting—it will basically treat it like plain-text, as if it had come in from a program like BBEdit. That should theoretically strip out any gremlins, and it will also cause the text to be pasted in using your application defaults.
'twould appear that the last problem you mentioned is the issue … some of the material I wrote in Word (before getting Scrivener) and pasted into Scrivener. I tried importing the project into a new project. Even though I had changed the global format, the project imported as it was in the original. Scratch the easy solution. Your idea of duplicating documents works, as long as you do a one for one replacement document by document. That means each scene in each chapter that came in from Word needs to be recopied separately. Guess I have to do it, but it will be a job of work. On the bright side, the global format reset did work, and the newly copied stuff appears to come through with the new indents I wanted. Of course, all the special formatting (quoted song lyrics, mostly) went away.
It’s still good software, even though the user manual is weak at explaining things…
Thanks for putting in volunteer time on this.
Regards,
John
I’m always looking to improve it, care to be a little more specific? Most of critique I’ve received has been more about finding thing, rather than the descriptions themselves. Organising stuff so that you can find where you need to go, even if through cross-references, is something I’m constantly tweaking.
Just in case anyone else is reading this thread, if you’re new to Scrivener and have material written in word, you might consider saving the Word document as .txt or .rtf, then copying and pasting that. I imported a rather long document into Scrivener from Word and now, 6 months later, I can’t easily control indents. Apparently the consequence of importing the Word doc.
Historically speaking this is quite true, and to a certain extent it probably always will be. RTF is much easier to work with than DOC/X files, and in the past and current versions of Scrivener the importer for DOC/X files has been provided by Apple as a free part of their OS X development kit—it’s a bit buggy though. The RTF importer on the other hand is more open and Keith has been able to update and improve it over the years. It remains the fastest and cleanest way to transfer files between word processors.
In the future (as in very soon now) we will be including new converters which use Java to import/export .doc/x and .odt files. This will be slightly slower, but produces a much better result than the freebie Apple converters that have been in use. They should (hopefully) eliminate weird glitches like this for good.
If you’re feeling experimental, you could try exporting the entire draft as an OPML file. Just select it in the Binder, use File/Export/OPML File... and enable “Titles and Text”. Then drop that file back into the Binder. It will expand back out to the original organised outline, but with all of the text “rinsed”, having been treated as plain-text. You’ll want to keep the original around so as to restore any in-place formatting as a reference.
Another approach would be to go back to Word and save the document as RTF, then go back through in Scrivener with the Documents/Split command and cut it back up. Since you have a pre-existing copy that is already split, this will be made much easier than the first time. You can just go down scene by scene, search for the first sentence, split, search for the next first-sentence, split, and so on.
Slightly OT: I’m afraid I don’t agree. The more I explore other shareware - and find that manuals are often vestigial, or perhaps non-existent, even for quite complex applications produced by larger developers - the more impressed I am by the Scrivener Manual and the detail and depth that it contains. Delivered extremely quickly too, as I recall. (That’s not to say that it shouldn’t be constantly tweaked - constant tweaking being yet another feature that many other manuals lack, being frequently unrevised and one or more updates out of date).
As Hugh says, the manual has a great deal of detail. That said, in the case we were talking about here, admittedly a pretty obscure problem, I spent an hour or so searching the manual trying to figure out what’s wrong. Keyword searches didn’t bring me much, and using the index was not too helpful. There could be a little bit of British English vs. Standard American Microsoft terminology, too, but that’s certainly not fundamental.
Leaving aside the fact that it could well be a problem with my wetware, not your software, the fundamental issue is that this is a very powerful, very complex software. I’ve been using it for 6 months, and I’m just getting into some of the kinks and twists. I went through the tutorial early on, and I probably didn’t fully understand the organization (document/folder/etc.) My sense is that the tutorial and the very helpful YouTube snippets explain the theory of the software very well. The issue of complexity is not going to change. It might be well to do a YouTube that sets up a generic novel (and explains the choices made), a generic non-fiction piece (w/footnotes, etc.) and a generic screenplay. Also, you might say in the tutorial something like, “This is software for serious writers. Plan on a learning curve.”
This particular problem is currently documented here:
Part I “Preparation”, Chapter 11 “Gathering Material”, which opens with a section on file import, on page 111. The process of how files are imported (duplicated) into a project and internally converted to RTF is described, and then in the Supported File Formats section, RTF is listed as, “The universal rich text standard; note that this is often the best format to use for importing from word processors, as Scrivener can import footnotes, comments and images from RTF files but not from DOC files.”
DOC/X is described in the bullet below as, “As with TextEdit, Scrivener ignores images, footnotes and comments in DOC files, so if you have these elements in your documents and need them preserved when importing, re-save the file as RTF in Word and import the .rtf file into Scrivener instead of the .doc file. Only Leopard and greater supports .docx files.”
This could have perhaps emphasised the formatting issues a bit further, but like I say the level of format locking that you experienced is rare. Most people who try to use the .doc/x importer find out that it screws with their document look or drops features and so consult the manual or forums and figure out that RTF is the native and best format to use.
Eh, I hope this doesn’t come across as me disagreeing with you—I’m only pointing all of this out to illustrate one example of the organisational logic in the user manual in the hopes that it makes it easier for you to find topics in the future. The idea behind the location of this particular explanation is: Stuff you do before you start writing = Preparation; pulling things together into your project so that you can keep everything in one platform = Gathering Material. Then within that we have the various ways in which one may gather and the various things that could be described as “material” File import is one of the top things anyone does with Scrivener, starting a new project, so it’s located at the top of the chapter.
The problem of course is that you were coming across it from a trouble-shooting angle. You probably weren’t thinking in terms of how you might have originally imported the file, let alone that you imported it at all, could be related to the fact that your ruler wasn’t working. That’s a whole different problem—and much more difficult for me to address with organisational logic since you get into the realm where there are thousands of possible ways to arrive at the two bullet points that push you toward using RTF. Your route is just one of many, and one of the rarer ones, so for you in particular, this was a difficult find. I wouldn’t blame your wetware—nor would I blame the user manual for being weak either. It couldn’t possibly equivocate on every known issue of every level of obscurity in every description. It would cease to be a functional user manual.
I don’t know about that—it’s a subjective statement. In fact the Quick Tour in the user manual demonstrates the opposite. While it speaks on the notion that the software has a lot of depth, it then immediately states that one can use it like a simple notepad, and then demonstrates how to get writing immediately, with very little training at all. So, we don’t really feel one needs to approach a “steep learning curve” to use the software in general.
To get lots of use out of it? To dig into some esoteric branch of it like modifying how your compiled output headers change on a per-section basis? Sure—yeah, there is a lot to learn and a lot of it requires knowing a lot of other things—no contest with you there. But to write? All you need to know how to do is click on the right thing in the binder, click in the text editor, and operate your text entry device. The tutorial is at the “how do I write” level, and I think it adequately demonstrates, toward the end of it, that the path outward from the tutorial is a branching tree of things you can learn and ignore. Some may take that as complexity and a steep learning curve, others might not. I think it is best to leave judgements like this up to the observer.
I do agree with you in that diving in without going through the tutorial probably made things more difficult. You might have run across another paragraph in the step on importing that advises you use RTF.
Anyway, hopefully like I said before, this will become an historic issue. The new version of Scrivener will be better for importing .doc/x and .odt files. And I am sympathetic with the jam you got stuck in; hopefully my OPML trick above saves you some time.