See entire text rather than summary in outline view? (Or, make summary full-length?)

Scrivener Scrivener for macOS
1

I’ve imported several Microsoft Word “outline format” documents, with the option to split them up and obey their outline structure.

It works great, except that when I select the entire directory tree (meaning, the root level that corresponds to the original imported document) and select Outline View and View/Outline/Expand All, I can only see the first couple of lines of each item (the “summary”) followed by an ellipsis. If I click on the individual items I just see the “summary” again in the pane on the right – there’s no way to see the rest of the item unless I open it directly.

Is there a way around this? I’m extremely dependent on these outlines: they’re the main reason I’ve been forced to stick with MS Word for so many years even though I hate it. Scrivener’s ability to parse and import them is a lifesaver…but I can’t work this way, where I can’t see the entire outline text in one glance.

Thanks in advance for any help or advice anyone can offer!

Jordan

2

Have you tried Scrivenings mode?

Katherine

3

That shows all the text but it removes the outline structure (the ability to expand/collapse sections; see indented hierarchies, etc.). So it defeats the whole purpose.

If you’re familiar with Microsoft Word’s “outline view” feature – taking an outline into “Scrivenings” mode in Scrivener is the equivalent to taking a Word “outline format” document out of “outline format” so that it’s just a flat series of paragraphs.

–

I don’t know why Word’s “Outlines” – which to me are the single most valuable feature of the entire Application – are so impossible to reproduce anywhere else. (Mac Applications that can otherwise read “Word” documents perfectly – like Finder preview or Text Edit – can’t handle Word outlines.)

I love Scrivener and want to use it for everything — it’s some of the best software I’ve ever encountered – but it can’t reproduced Word Outlines; it can only convert them into folders full of text clippings (which are then visible in hierarchical form, but with the text truncated). I would pay good money for this feature – for a version of Scrivener that could import a Word document in Outline Format and then simply show it to me in Outline format (or, even better, in editable outline format) with all fonts, colors, highlights etc. but also with structured hierarchical indents. For me this is the holy grail.

4

There is one very important difference between the kind of outline view that Word provides, and the kind of outliner that Scrivener is:

  • The former is based entirely upon the stylesheet of the document; in order for there to be outline detail there must be outline level styles in use, and these correlate directly to visible text in the document. I’m not a Word expert, so I might be simplifying things a little bit, but I think I’m generally right in saying that for a document to have structure that structure must be a component of what the reader will see as structure as well (chapters, sections, subsections, etc.).
  • Scrivener’s outline is different. For one thing it’s a “real outliner” in the sense that it describes structure outside of the document, and has significant features for manipulating, tagging and working with the outline itself. Components of that outline can become printable components of the document, but they do not have to be. You can have a folder that does nothing in the output because it has its “Include in Compile” checkbox turned off—or you can even classify all folders from levels 3 and up to be purely for internal organisation, not compiling into the output.

The synthesis of these two different approaches is that a Word outline is limited to what you can see in the document, it can never be more detailed than that, while a Scrivener outline can be greatly more detailed than the sum of what it produces.

So that it does not have a Word-style outlines is a feature, not a missing ingredient. :slight_smile: It very intentionally does not take that path to its conclusion, because the idea behind Scrivener is that the sort of outline an author needs might not have much to do with what a reader needs. Word and similar word processor style programs take the approach that both the writer of the document and the reader will adhere to the same structure.

An extension to all of this is that if you feel Scrivener doesn’t have enough outline depth for you to work with the document, then maybe you simply haven’t built enough outline yet. I have areas of my outlines that consist of single-paragraph sections of text, for example, where I need it. I don’t always need that kind of detail, and so I’m glad that Scrivener lets me define how much detail I need, where I need it.

I don’t know why Word’s “Outlines” – which to me are the single most valuable feature of the entire Application – are so impossible to reproduce anywhere else. (Mac Applications that can otherwise read “Word” documents perfectly – like Finder preview or Text Edit – can’t handle Word outlines.)

So to dive a little deeper into the technical mechanics of what is going on: there isn’t an “outline” buried somewhere inside the RTF file that everyone is just ignoring. That’s a very specific interpretation of a document’s internal stylesheet settings which has been programmed to turn styled text into an interface that provides outliner capabilities.

TextEdit doesn’t even know what a stylesheet is. We had to add that by hand to Scrivener because no Mac development tools work with styles at all—let alone parsing styles into an outline, let alone the tens of thousand of lines of code it would take to make an actual outline that you as a user can click on and do stuff with. Such a complex task is arguably grounds for an entirely new piece of software!

That sheer scale of what you are suggesting everyone should just do aside, it could of course be done, but there are two big problems with Scrivener doing so:

  • It’s not feasible—at least not with a rich text editor base to work from. The Mac rich text editor cannot arbitrarily hide areas of text that are in the editor. So folding is out—which I would very much agree with you in saying is a shame. It would be really nice if Scrivenings could be folded in the editor interactively, and I doubt anyone could mount a serious defence of it not being included.

    It is worth noting that Scrivener of course does have a concept of exclusion. While you cannot fold in the editor, you can achieve similar results by how you select items in the binder for viewing in Scrivenings mode. E.g. Shift-clicking a range of nodes and then Cmd-clicking out the ones you don’t want to see.

  • Folding aside, why would Scrivener spend huge amounts of code to create a Word-style outline when it isn’t even a document-based editing program? It is designed to operate as an outliner, with lots of little snippets of text in nodes, not one huge massive document. Stylesheet level outline parsing would work counter to its design premise of having short chunks of text in each outline node.

The above all aside, there is still the matter of indents and paragraph-level treatment. We don’t indent in Scrivenings for two reasons:

  • Scrivener’s outline is so much more flexible than Word’s, with regards to what is document structure and what isn’t (and indeed that its outline can be entirely unrelated to documents at all, such as a repository of snippets from Web research, topically organised into folders). There are many places where indenting wouldn’t at all be appropriate. So it would be a lot of work for something that would only work for a few things.
  • This one might also fall under the “impossible” arena as well as folding, in that the Scrivenings text editor is a singular text editor. Just because it is comprised of potentially hundreds of different file sources on the disk doesn’t mean it is a stack of 100 text editors in a single scroll view. It’s one text editor—and a rich text editor at that. So what is an indent in that case? Surely you wouldn’t want it to be actual formatting indents, so what then is creating this indent inside of a text file?

Paragraph-level nodes are a curious case, but if you go back to the design roots, it makes sense. Scrivener doesn’t consider lines to be outline elements because it is a “real” outliner, not a program parsing a text file into an outline. That doesn’t mean line-level automated outline nodes couldn’t be implemented, the question is whether they should. A real outliner has you definining what is and what is not significant structure, not the document, its formatting, nor the content within it in any way. You must establish what is meaningful outline detail and what is not. Word doesn’t have a facility for that. You can’t say that these 25 paragraphs are really not significant enough on their own to be taking up space on the outline as elements. In Scrivener that’s the default assumption—but you can still create paragraph level structure if you need it. The outline “resolution” can scale organically, as you need it, not as the document requires, or because it has paragraphs.

By the way: in Scrivener 3, hierarchy is minimally telegraphed in Scrivenings mode through the font size of section titles, when View ▸ Text Editing ▸ Show Titles in Scrivenings is enabled. The settings for how that works are found in the Appearance: Scrivenings: Fonts preference pane. I like to use a large top level font (36pt) with a larger drop per level (9pt), to help visually accentuate the outline structure of the flat document I’m editing.

But if I’m even at a loss and need to better know what the Scrivenings session looks like at the outline level, that’s no problem at all—just hit ⌘3 to toggle Outliner view on, and the section my cursor is in will be highlighted on the list. I can hit ⌘1 to return to writing, or even select another area of the local outline before doing so, treating the outline as a large “table of contents” for the current editor.

In closing: I don’t mean to suggest that our way is better or Words is inferior. We do of course feel there are advantages to the way Scrivener works—obviously—but such things are subjective. Some people may like how Word’s outline works more than Scrivener’s.

You are in essence saying we should throw away the whole Scrivener idea and just do what Word and other word processors do—you can’t really mix these two ideas together into one program. That is of course problematic when many of the people who have adopted Scrivener did so because they do not like how word processors handle large-scale document management—and when the guy who made Scrivener did so precisely because he never liked how Word outlines and stylesheets worked in the first place. :slight_smile: I understand you like it—just keep in mind Scrivener was made for people that don’t, as an alternative! Expect it to be intentionally different, and hopefully find that although it is different, it has a rich and fully supported concept of that alternative.

2 Likes
5

This is absolutely amazing – beyond my wildest hopes, in terms of responses to discussion-board tech-support queries. I can’t thank you enough for responding so thoughtfully and in so much detail.

If I may, I’ll get deeper into the technical/procedural questions here in a subsequent post…but while I’m carefully poring over what you wrote, I just wanted to quickly respond with an enthusiastic and heartfelt “thank you.”

What you’re saying here reinforces my suspicion that I need to go forward, deeper into Scrivener, rather than backwards, retreating into the world of Word Outlines (which I’ve been dependent on through countless articles and two books). It’s gratifying to finally be discussing this in detail with an engineer/developer; most people don’t know what I’m talking about when I bring up the topic.

Thanks again, and (as I said) I’ll follow up once I’m satisfied that I fully understand all the details of your post.

Jordan

6

You’re quite welcome! I look forward to discussing any further matters of implementation. I’d say as a general rule of thumb: look to how Scrivener’s features work with binder items. The Documents menu, Quick Search, metadata in the inspector, Collections, search results, etc. The other thing Scrivener is unusual about is that it has lots of little tools designed to be combined into larger workflows. There isn’t a “character tracking” feature, because we have three or four features that can be used to create a character tracker—that can also be used to track individual species in a book on migratory birds.

Oh, I forgot to mention, you can download a copy of the Scrivener user manual as a .scriv project, if you want to see a functional example of an extremely detailed outline (~2,500 nodes in the Draft folder) that takes this organic approach to how detailed the outline should be, based on what I need of the outline in that particular area.

7

Okay, I still can’t claim to fully grasp everything you’re getting into above, but while I’ve got your attention, I’ll provide a couple of responses, one short and one long:

  1. The short version of all of this: When I take one of my complex, elaborate Word Outline documents (upon which, as I’ve saying, I’ve grown totally dependent on over decades), and import it into Scrivener (where it arrives as a binder), if I select that Binder and choose Scrivenings view, I get all the formatting (color codes; font sizes etc.) and when I choose Outline view, I can see my entire hierarchical structure with folding but I can’t see all of each item; they arbitrarily cut off after a certain number of words (the “Summary”) and even if I select them individually and look at the right-hand pane, I still can’t see the remainder; I have to select the item and view it in isolation.

So, two views, each with compromises: the Scrivenings view shows my color-coding but not the folding hierarchy; the Outline view shows my folding hierarchy but not the entirety of each entry.

I understand and accept your elaborate explanation for why altering the Scrivening views, to show the folding hierarchy, is not possible.

But what about the other way? What about making those summaries be the same length as the text files they represent? What about some kind of Macro or hack or adjustment to the import process – something called “Reproduce entire text file as summary”? That doesn’t sound prohibitive, like it would break the functionality or the concept of Scrivener. And it sure would make my life easier, right now in the short term.

  1. The longer version: Let me use my current novel as an example. (I’m on the third draft.) For the first two drafts, I had an individual Word file for each chapter and then a “master file” with links that would embed those. I assigned outline levels to the Styles that governed chapter breaks and section breaks so I could switch into Outline View and collapse the whole book down to the first lines of each section. It would have worked great except that Word’s “embedded file” mechanism is totally buggy and broken and I nearly lost the entire book more than once. This entire functionality was reproduced perfectly – and improved! – in Scrivener. Now I can fly around the book as deftly and quickly as I need to.

The Word Outline document I’m discussing essentially runs parallel to this: it’s years’ worth of ancillary data (notes/proposed draft material/research/web-links) all organized by chapter and section.

What I’d love to do is integrate all of this into a single Scrivener binder, so that I can look at the book, section by section or the entire book, and see the existing text, the new text (as it evolves), and/or the notes/ancillary material (all of it; not a summary) with all my color coding, formatting etc. I suspect this is how I’m “supposed to” use Scrivener. I’d love to be able to combine both imported structures – the book itself, with its chapter/section breaks etc. and the long outline document, containing all my notes, with the same structure – so that they’re a single entity rather that two entities with matching structures.

Shortest possible version: if I could remove the arbitrary length limit on the visible summaries, I’d be very happy (although I realize this is a short-term solution). As things stand, I’m going back and looking at the original Word Outlines solely for the purpose of being able to scan my eyes down the structure and not having the sentences end with this tantalizing “…”

The option to show titles in Scriveners doesn’t help, since those titles are already there; it just reproduces them centered over themselves.

Thank you, again, for engaging with me on these questions. I’ve been pining for a way to escape the horrible prison of Microsoft Word for so many years…Scrivener has almost set me entirely free.

8

Also: I would use the “corkboard” if:

  1. I could see the text formatting (I really am dependent on those color codes – maybe there’s another color option I’m missing, that would tint the entire card)

  2. The cards didn’t take up so much room onscreen! Before committing totally to digital editing of my writing, I used to print out long documents full of notes/fragments/scraps, cut them up physically with a pair of scissors, and then arrange them on boards (with clips or tape) so I could rearrange them. They were little ribbons of paper, each with a line or two of text. (I was allergic to index cards as a student, too—it goes all the way back.)

I would do this in Scrivener, except that every card takes up a full card-sized rectangle of space, even if it’s only containing a few words; and, I can’t arbitrarily zoom in and out.

9

View -> Use Label Color In -> Index Cards will tint the entire card based on the applied label.

The little icon with four cards at the bottom right of the corkboard view allows you to adjust the card size.

Note that you can split the Editor pane (View -> Editor Layout), with the body of your manuscript in one pane and your preferred view of your outline in the other pane. And you can use Quick Reference panels to pop whatever pieces you like out into separate windows.

Katherine

10

One suggestion (note: I’m a customer like you, not affiliated with L&L) – I don’t know what version of Scrivener you are using, but if you are on Mac v3, try the built in “Three Pane (Outline)” layout. This sets up a split view editor Katherine mentioned without needing to tinker with other settings.

Just to sell you on this view a bit (because I’ve found it extremely useful myself) – once you are in this view, you’ll have the binder on the far left, the Outline view with your structure in the middle, and an editor that displays full text on the far right. Click in the binder to load a section into the outliner (maybe the entire draft/manuscript? Whatever level you want). Click in the outliner and you’ll see the full text of that document in the right pane. You can easily see structure and full text side by side. IMO, this is far superior to the Word outlining model, where expanding a heading to see the full text pushes the headings below out of view (assuming you’re working on a long document). With the split screen version, you can see lots of structure while also seeing the full text of the selected document.

Also, if you click on an item in the outliner that has sub-documents, you can put the right pane into the scivenings view as well, to see the text of all those subdocuments together. It is a very flexible system, as you can easily see any level of detail you want, all on the same screen.

There is a similar pre-built layout that does the same, but with the corkboard instead of the outliner if you prefer that.

One other note that I’m not sure was touched on in the other replies, you’ve referred a few times to the outliner/corkboard displaying truncated “summaries” of your text. I just want to point out that these views display the synopsis for each document. The synopsis is a separate place to enter text about the document. I think the outliner/corkboard views default to showing you a bit of the document text in the synopsis if it is blank, but it is still a separate field, meant to contain a description or notes about the document rather than the actual document text.

This may be irrelevant since this is an in-progress project you’ve imported from Word, but you may find them useful in a future project. Much like plotting a chapter on physical index cards or something – write a description of what you plan for each scene, arrange them in the corkboard/outliner, then write the actual text of each scene in the document. The synopsis remains as a completely separate field, not connected to the document text.

11

With the utmost respect and gratitude to the people offering these suggestions – and, at the risk of sounding like a kid throwing a tantrum – I don’t want to have to use a three-pane view just to see the remainder of a line that’s arbitrarily truncated in the outline view; I want to be able to change a setting (or use a third-party plug-in) that says “Show entire text of item as ‘summary’ in outline view,” (“Show formatting in outline view” would also be nice, but that’s a bigger deal and less necessary.) It’s the simplest solution all the way around and the one that solves the problem most elegantly.

I feel like this is something a coder could add in five minutes. (I’m not a software engineer myself, obviously.)

ON EDIT: There could maybe also be a “macro” or plug-in that goes through a section of a document – say, during an import – and copies the full text of each item into the summary. (Since that’s what’s happening anyway, right? The “summary” is a separate field in the database, not just a re-presentation of the main text field.)

12

What is actually happening is that Scrivener is automatically generating a synopsis on the fly from the body text of the document. This auto-generated text can, at your option, be replaced with a separate synopsis.

But that means that the text you’re seeing actually exists in one place and in one place only: the body of the document. It isn’t “arbitrarily truncated,” it’s truncated to fit the space available in the view.

Because of that, “showing the whole text in outline view” would mean completely re-organizing how outline view works. Definitely not a five minute task.

Katherine

13

Then, is there a way I can increase the amount of space available in the view? Increase the vertical or horizontal dimensions of the cell in the (implicit) table?

Experimenting with the width slider provides more space for each summary, beyond the implicit cutoff point where the ellipsis was placed, but more text doesn’t flow into the newly-provided space. (In other words, that “on the fly” truncation, when the summaries are generated, only happens once, based on an arbitrary length…which it seems to me could be changed; it’s got to just be a character count somewhere.)

Alternatively, if I go to the summary and add text before the ellipsis, and hit return, that text appears in the Outline view; suddenly there’s a third line of text visible (when previously there were only two). The summary isn’t dynamic: it’s created once, truncated to a pre-determined length, and that length can henceforth be changed manually by the user.

So, therefore, if I

  1. Went through every item in the binder;

  2. For each item in the binder, copied the text

  3. Pasted that text into the “summary” field

Then I would have the result I wanted; I could see all the text of each item in the Outliner, exactly the way I’ve been describing all along. It seems to me that a macro or plug-in could pretty easily do this; just loop through the selected binder and perform that cut and paste for each item. It doesn’t seem like it would interfere, or force a rethinking of, the core Scrivener functionality at all.

14

I’ve determined through experimentation that this is not the case.

As I elaborated on in my previous reply, I can add text the summary, making it longer. That newly-added text does not appear in the original item, when I open it in an editor. Scrivener is keeping track of the text and the summary separately; they are independent pieces of data.

The summary is made from the item when the item is first imported or entered; from that point on they are independent and may be edited to read differently from each other. (So, the “macro” I’m recommending that copies the text into the summary would work, as would adjusting the variable or whatever it is in the Application that chooses where to cut off the text for the summary, or, putting that variable under user control, as a preference.)

15

The second you edit that summary, you’re effectively creating the summary – you’re simply starting with the default suggested text that Scrivener provided, generated from the document body. If you didn’t edit the summary, it wouldn’t fill that value in, and the suggested text would mirror changes to the body text.

Now that you’ve edited the summary, if you go back and edit the document body, the summary will no longer track those changes because now you have a value in the summary – it’s no longer empty.

16

Interesting! (And, thank you very much.) But, respectfully, experimentation disproves this as well. If I open an individual text item in an editor and change it, that change is not reflected in the Summary: the Summary remains as it was.

So half of what Katherine wrote was correct, and half was not. When she wrote

That was correct — and, respectfully, this is where your description is incorrect: the Summary is already a different piece of text from the body text it’s copied from; you can already edit them separately. Katherine went on to say

This isn’t correct; from the moment the text fragment (“document”) is created or imported, its Summary is a discrete piece of data.

“Arbitrarily” or not (and, all I meant by arbitrary is that it’s a word-length or character-length that may be triggered by the size and dimensions of the document window or other factors — as she’s suggesting — but has nothing to do with the document text itself; it’s an external imposition). At any rate all of this happens once; contrary to what Katherine says, the main document text and the Summary text are not two views of the same data (“exist[ing] in one place and one place only”); they’re two separate things — and, despite what you said, this split doesn’t happen when you start editing the Summary (if it did, then changing the main Text would have those changes immediately reflected in the Summary, and they aren’t).

I admit that “five minute task” is facetious and I apologize for that. But, with utmost respect, this would be correct — it would be a fundamental change — if the program worked the way Katherine is describing…but it doesn’t. As I see it, the way to make the program work so that my complaints are addressed (and, I realize how imperious this sounds, and regret this! I’m simply trying to be clear):

  1. Make the Summary match the text (either at the beginning, or when prompted, or when either is changed)

This is a bad solution, and is probably impossible; it really would change the program’s fundamental function. And it shouldn’t be done anyway because text is text and summaries are summaries, and the advantages of having a separately editable summary are obviously manifold.

  1. Change the automatic Summary word/character length (or, make it a user option, either globally or during import)

Somewhere in Scrivener is the mechanism that creates the initial, automatic Summary, the first time (before the user has edited it); it cuts the text off a certain point. That point could be made into a user-controlled variable. There could even be an option for “include entire text.” (The view gets truncated anyway, when the cels of the Outline table get smaller.)

This would suit me better than what exists now, but it’s still less than ideal, becuase while I could now see the entire text (as an identical Summary) in the Outline view, I couldn’t change it, since I’d only be editing the Summary; not the text itself.

  1. Make “full text” an optional column in Outline View

This cuts the Gordian Knot and serves my editing needs while not violating any of the program’s core functionality or introducing any changes to anyone else — everybody’s happy. When you right-click on the column headers, you see a list of possible colums—one of which could be “entire text” (de-selected by default). This is vastly better than anything I recommended above; it doesn’t change anything anyone’s used to. It’s perfect.

Again, a heartfelt thank you to everyone who’s taken the time and put in the effort to respond and discuss this. Please, again, don’t mistake my tone! I absolutely love this program — it’s freed me (nearly) from a Microsoft prison I’ve been trapped in for decades, through two published books. Everyone involved did a brilliant job. There’s just, again, this one element that has me running back to the hateful Microsoft Word and I really would love to be able to see it augmented.

Thanks again,
Jordan

17

I think you’ve discovered a new (to me) behavior applicable specifically to outline-format Word documents. I just tested, and can confirm that the Synopsis is not automatically filled with real text when importing an arbitrary RTF file into Scrivener 3.1.1.

If that’s the case – I don’t have a document handy to test, but I have no reason to doubt you – then the Synopsis is generated as part of the Word format conversion. Which is bad news from the point of view of your feature request, because the format converter is a third party tool and something of a black box. I’m not sure how much control Scrivener has over the length of the Synopsis, or if the summary is defined as part of the Word file and the converter just puts that in Scrivener’s Synopsis field.

Because the Synopsis is a separate piece of data, filling it with the full text of the document would effectively double the size of the imported file: you’d have to import everything twice. You’d also have to deal with whatever non-text elements might be included: tables, images, all sorts of things that aren’t really compatible with the Synopsis field as currently defined. So it’s (potentially) possible to make it longer, but probably not workable to make it arbitrarily long. And, as you said, it wouldn’t solve the problem, it would just let you get two nearly identical copies of your documents out of sync with each other.

I can’t speak for Keith, but I don’t see him being excited about your Gordian knot solution, elegant though it sounds. Individual sub-documents are usually hundreds and potentially thousands of words. Wedging all of that into the Outline view – along with everything the Outline already does – seems likely to create an interface nightmare, making it nearly impossible for the user to figure out where they are. And since Scrivenings mode already exists, and since you can already open arbitrary documents from the Outline view in a Scrivenings view, it’s not clear that your approach would provide enough of a benefit for enough users to justify the complexity.

Katherine

18

Katherine, once again thank you very much indeed for replying at length (and, again, for tolerating my detailed and incessant questions).

It’s too bad that the Word importer is so impenetrable; I would love to be able to adjust the length of the portion that’s copied over to the Synopsis…but I understand it’s not feasible.

Showing the complete text of each document in the Outliner, with an arbitrary cut-off point (the dynamic, “this is the edge of the cell” cutoff; not an actual truncation) seems like it might still work. The rich text/embedded image etc. stuff wouldn’t be a problem because, like the rest of the Outline view, this proposed new (optional) column would not have any formatting; it would only display plain text. (Maybe there would be an icon saying [IMAGE] or whatever.) Everyone understands that you can see it all for real by switching to Scrivenings view.

I have worked with entire books as outlines, in Word…assigning outline levels to the styles for the book sections and passages (as I explained in a previous text). It works well, even though some of the nodes in the outline are hundreds of words long…when I switch to Outline view they get arbitrarily truncated with elipses (and, unlike Scrivener, this really is done “on the fly”; it’s the same text, not a summary.)

As I said, I’m amenable to the prospect of simply trying to change my own workflow, to adjust to Scrivener, since it’s such an excellent writing environment all the way around, vastly superior to everything else I’ve tried. If it means breaking my addiction to Word-type outlines – or, continuing to use Word to work on those outlines – I don’t like it, given how dependent I am on them, but Scrivener is so good that I would like to do it.

If there was a “preview pane” that showed not just the summary text but the whole text (without advancing to a new window)…or if there was a macro that let me copy the document text into the Summary field…(insert wistful sigh). I realize these aren’t feasible or reasonable given Scrivener’s scheme. For now, I’ll have to continue using both programs concurrently, and copying data back and forth, as much as I’d love to switch 100% to Scrivener.

Thanks again for your time and attention to my queries!

Jordan

19

Preview pane? Well, if you right-click on an item in the Outline view, you’ll have the option to open it in the current editor, the other pane of a split editor, a Quick Reference pane, or the Copyholder. And you can use the Navigate -> Outliner Selection Affects menu to open Outliner selections in either the Copyholder or the other editor split automatically. So it’s not like there aren’t options.

Katherine

20

Okay, so I was partly wrong, but not where you say I am.

Open a new blank project. Create a new blank folder under Drafts titled “Testing” and with no content of its own.

Put two text documents in the folder – don’t title them.

In the editor, put “This is body text A.” in the first document and “This is body text B.” in the second document.

Now, focus on the Testing folder and go into Outliner. You will see the body text for both documents show up in the light grey that shows it is auto-generated.

Focus back on the first document. Add “And this is too.”

Focus on the Testing folder. You should now see “This is body text A. And this is too.” in the auto-generated synopsis of the first document. This worked for me in both Mac 3.1.2 and Windows 2.9.0.11.

Now, go into Corkboard mode and click on the first document. Type something (this is where I was wrong before, the auto-generated synopsis is not default, the field clears up) in here. You can even paste in “This is body text A. And this is too.” in this field so it looks the same as the body content – but once you save this data, the auto-generated synopsis is no longer created on the fly and the value of the field takes over. Focus on the Testing folder. Whatever you typed in here is now the normal synopsis.

If you go back in now and continue to edit text in the body, of course it will no longer be generated into the synopsis – even if you pasted in “This is body text A. And this is too.” The auto-generation only works if the synopsis field is empty. In fact, when you go back into corkboard and remove the manually created synopsis, the auto-generation comes back with whatever is in the body content.