Compile synopses for some, text for other same-level items?

Hi,

Is there any way to tell the Compile dialogue to include the text of certain items, but only the synopses of others, without changing their level within the document?

I need to submit a “whatever you have” current draft of my dissertation to my advisor - some of my binder items are complete chapter drafts, others are still just a heading and a bunch of notes to myself. All chapters have synopses that I wrote during the outline stage.

Ideally, I would like to be able to hit “compile” and have the complete chapters appear with their text (no synopses) and the others without their text (which is unsubmittable) but with their synopses. To get there, I could either click the appropriate option for each item or use a filter by label or status. However, as far as I can tell, the only way to do this is by changing the level of one set of documents, but there are a ton of them, and I would be messing with the carefully arrived-at structure of a 500 page dissertation, so that’s not an option. The other way is to include text and synopsis for each level and then manually delete one or the other in the compiled draft. Better, but obviously not ideal.

It seems that the first pane of the “Compile” dialogue (“Contents”) should have this option, if it existed. Any ideas?

Thank you very much,
Kathrin

I cannot think of a really good way to do this. Levels and icon types are the way to accomplish various more complicated formatting tasks, but that doesn’t help you out for this particular wish. One thing that might work: if these items do not need to print a title, use As-Is on the ones with text, then leave the Formatting pane to export synopsis. As-Is opts items out of that pane entirely, so the synopsis wouldn’t be printed if as-is was toggled, only the editor text. But, as I say, that opts the item out of the Formatting pane, if it needs a title, otherwise generated there, that won’t work for you (it kind of sounded like you might have your titles in the text itself however). It also could be problematic if you’re using override formatting, because as-is will use the original editor fonts and paragraph settings. So that method has significant drawbacks, but it would be pretty easy to manage these checkboxes. There are good tools for doing that kind of stuff, so let me know if you’re interested and want some tips.

Hi Amber,

Thank you for your response. Using as-is is an excellent idea, but not only do I have titles, I have fairly elaborate hierarchical numbering and numbering (nearly 200 binder items over six levels), so I think the effort involved in moving the titles to the text and doing the title-formatting and numbering after compiling would be no better than going through and deleting text/synopses (especially as this is not final-product formatting, so I’d have to remove the titles again). But I love the idea of the workaround!

I wasn’t sure from your post, would the tools you mention be able to help me nevertheless?

Thank you again!
Kathrin

Okay, I don’t think As-Is will work well for you in that case. You could move all counter tokens and titles into the text, but that’s a huge pain, and I would consider it a less agile (and messier, since you have tokens everywhere in your face) way of using Scrivener anyway. I’d much rather recommend people move their titles into the compiler, than the other way around.

Putting that aside, I think I have an idea that could work even better, using a non-invasive technique! Sometimes it takes a good night’s rest. :slight_smile:

The only snag in my method is multi-paragraph synopses. If all (or most) of your synopses are written into a single line (excluding soft word-wrapping of course), then this will work. If a synopsis has more than one line and also comes along with a fleshed out text document, then it will not match and be removed. So you could still use this method if the majority are one-liners, as searching for the strays would be pretty easy in the final output.

Okay, here’s the trick. As you’ve probably noticed, when you have both a synopsis and a text file compiling for the same item, they get subheads (unless you turned that feature off, you’ll need it on for this to work). This forms a predictable pattern in the text that we can look for and handle.

[code]Synopsis

Text

[/code]

When we see that pattern, we know a document has text and thus doesn’t need to print the synopsis. Our search and replace can look for this entire pattern and dump all of it up to the editor text.

To do this, we’ll use a Replacement in the compile pane. Copy as paste the following into the search field:

^Synopsis\n.*\n\nText\n

Leave the replacement value empty, and make sure the “RegEx” checkbox is enabled, as this uses advanced search syntax. The syntax matches the overall pattern in the text, with a wildcard block in the middle for the synopsis itself.

Next you might not want the “Synopsis” subhead that would be left behind on items that only have a synopsis and no text. If so, add the following on a Replacement line after that one above:

^Synopsis\n

Again, set RegEx and replace to an empty field.

I’ve done a few quick tests with some sample data, and it seems to be working fine, again, so long as I don’t write long synopses.

So like I say, if you have a multi-line synopsis the first pattern will not match, but there shouldn’t be any lines left with “Text”, so by searching for lines that contain line “Text”, you should be able to locate any cases that were not automatically stripped.

Wow!!! Thank you so much for your time, this is brilliant!! I had no idea the replacement tab could be used for this level of intelligent quest… is there a place where I can read up on how exactly that all works? What an elegant solution!

It doesn’t entirely solve my problem because a lot of the documents where I want the synopses to show up already have text (it’s just not in shape for my advisor to see it yet), but I am getting the sense that if you don’t have a solution for that, there is none. So I will make it work with this beautiful replacement strategy and put in a feature request for checkboxes.

Thank you so much for your help!
Kathrin

Hey, Ioa, would this work?

Set all your document’s statuses so that the ones you don’t want to show to your adviser are labeled with “not ready” or whatever makes sense to you. Then do a search on that status using the toolbar search field, using the option to just search in the status metadata field. Select all the documents in the search results set, and do the following:

  1. Go to Documents->Take shapshots with Title and give those snapshots a title of “pre-strikethrough” or something. (just in case)
  2. Enter scrivenings mode for the selected documents (if you’re not there already), and then select all the text (CMD-a). Go to Format->Font->Strikethrough.
  3. In the compile settings, under Transformations, check the “Delete struck-through text”.

Submit your compiled document, and then remove the strike-through as you encounter it in your documents.

Replacements are covered in 24.18 of the user manual, starting at the bottom of page 399. As for regular expressions themselves, that is whole well-documented general purpose search syntax that goes well beyond the scope of our manual. This online tutorial is where I like to point people who are interested in learning. It doesn’t take too much introduction to use it at a basic level, and even that will be useful for things such as the above.

I can’t think of anything automatic, as any software technique will have a very difficult time discerning the intent of your text. The trick we used is only merely “aware” of its existence through predictable patterns around it. The other problem, of removing arbitrary Text blocks, is similar to the problem we faced with multi-line synopses: the search engine doesn’t have the authority to freely examine multi-line variable blocks. In my original pattern, wherever you see a \n is a single carriage return. We know how many are in this text pattern, and so we can be precise about it, but without a special flag to tell RegEx to operate in multi-line mode, our wildcard will automatically terminate at the first carriage return within the synopsis that it discovers. In other words, RegEx itself can do this, but we’d have to start adding lots of checkboxes to let it do everything it can do.

So for this specific problem, my best advice would be to make use of inline annotations, a feature designed to let you write in the editor without “publishing”—mainly meant for editing notes and so on, how you might use a “red pen”, but if you enclose an entire early draft of a section in one, it will be stripped out (in the Footnotes & Comments compile pane), leaving no text, and thus only the synopsis. Note you can change the colour of an annotation using the regular text colour tool, to something more suited to bulk text (even just black).

I already have a note on synopsis-or-text as a possibility for compile in the future. I’ll add this thread URL to that document.