Ok, this might seem like an obvious thing, but I can’t figure out how to export just a couple of chapters out of a manuscript. There doesn’t seem to be a way to do it in the Windows beta.
I would have thought this’d be an essential feature, something like: ctrl-select chapters, export to file or compile, job done.
Am I missing something here? If not, I’d like to suggest that this get added ASAP.
You can do it in compile. Make sure you click the “…” box so you see the expanded options, and then in the contents tab you should be able to check or uncheck boxes for which documents to include in compile.
You can also just select the documents in the binder and do a “quick and dirty” export via File/Export/Files…
Compiling a selection is something that is already on the list of things to add. The tip MM gave above is the current best way. That’s what those check boxes are in part for: constricting the output to whatever degree you need. If you just need one chapter, and you have chapters arranged as scenes in folders, you could select the chapter from the “Folder” drop-down at the top of the Content pane.
I was going to say that you could use the Folder selector to isolate by chapter and bulk select everything in that view by Alt-Clicking on the checkbox, then jump back out to the Draft level, but it looks like the state of those checkboxes does not persist between folder selections. That might be a bug, I’ll see about it.
Thanks very much guys 
that’s got it solved, sort of.
I can confirm that if you compile and only select the folders - not the text sections in them - you get nothing but the folder/chapter headings, and no text. If you want to select a chapter you need to select every text section in it individually.
I’m compiling to PDF, but I expect it’ll work the same way regardless of the file format. I’ll check anyway.
I posted a bug about folder selections in the other forum - same thing, perhaps?
That’s exactly how it is supposed to work. In most cases (group views excluded) each item is treated as an individual item, and does not automatically assume that you want every other item beneath that item. In plain language, the include/exclude flag only applies to the item beside the checkbox, it will never bleed over into other items under any circumstances. So if you just check off the folders, that’s all that will compile, those two folders and any text they have in them, but not their sub-files. They need checkboxes too.
The reason for this is that there might be many occasions where one would want to exclude a container, but not its children. Say the container is only there to organise your thoughts in the binder—you don’t want that showing up in the compiled draft, so you turn off its compile flag. Of course, you still want the stuff in that container, just not the container itself.
In some future version, is there any chance that the checkboxes could get updated to the variant that understands nested content and adds a third “partially selected” setting?
For an example of how this works, take a look at adding and removing Windows components. This type of checkbox was around in Windows XP, so I would hope that the widget libraries the project is using would support them.
Actually we can do one better than that. In the future, this checkbox will become largely only used for static things that definitely are or are not a part of the draft. In addition to the compile group selection menu that already exists: This very menu will display more options, including the current Binder selection, and Collections. Secondary to that will be an optional filtering system, whereby you can include or exclude draft items based on particular bits of meta-data, whether or not they are selected, or whether they are in (or not in) a particular Collection.
Thus to compile say, two chapters with two folders and 45 individual components, you would merely add these chapters to a Collection, and then set compile to use that Collection as your compile group source. No messing with checkboxes, and you can easily administrate what gets compiled by the contents of that Collection.
So the difficulties with doing more complex and powerful selections with checkboxes is a temporary problem, and spending time beefing it up would probably not be the best time spent.
Sweet! That makes a lot of sense.
In this New Compilation World Order, will there be a way for me to take a particular selection (such as a text component) and assign a pre-defined compile style to it so that when I select it in the compilation option, the formatting is already defined?
The use I can think of this is for pullquotes, blockquotes, or other forms of text that I would logically treat as different text objects in the manuscript.
In a way, yes. The way it will work is by two components. First, more options in the Formatting compile tab to start with, such as how far the reformatting really goes. If all you use indents for is block quotes, then disabling that part of the formatter could be all you need. But for more arbitrary exclusions, the second component will be similar to an inline annotation in that you select a block of text, and that block will be protected from the formatter. You’ll also be able to specify how much protection that box provides. So for pullquotes, epigraphs, blockquotes, and anything of that nature, you can just draw a box around it and not worry about it getting homogenised like the rest of the manuscript. So there isn’t something like “Protect blockquotes”, but just “Protect any of these…”.
There will be a lot of really cool things coming along for compile, once this current build is stable and ready to go.
Huh. I come at this from an SGML background, where you wanted to separate the definition of styles and the definition of document structure. That’s been the only way I’ve been able to write in Word – to ruthlessly train myself to stop making one-off formatting changes in the main text and to make new appropriate styles in the style editor – then paint the correct styles onto my text in the document, typically after I’ve already written the content.
I am hoping, eventually, for something equivalent in Scrivener. I would love to be able to define a series of styles for the compiler, and then as I create/manipulate folders and text objects in the manuscript be able to associate them to a compiler style. That way I can go nuts on how I format the text in the manuscript to give myself as much metadata as necessary, and my compiler styles can be carefully written to override all of that to impose sanity and uniformity back onto the finished product. Some sort of a default hint at the text object level that tells the compiler how to treat that object until and unless I override it explicitly during the compile options dialog.
If that’s how it’s all going to work, I’m totally grokking it. If not, I’ll be patient and see how it all unfolds. Scriv is still the best writing tool I’ve ever used. About the only thing I could wish for at this point is a scriptable interface to easily add/manipulate/remove text objects/projects so I can use Scriv as a repository for auto-generated text fragments.
Hmm, in that case you might want to look into the MultiMarkdown side of things, which isn’t fully integrated yet on Windows, but shall be. What I’ve been describing is the more traditional approach, and for those accustomed to the traditional approach it provides a degree of content separation from style that is otherwise difficult to pull off in a word processor without understanding stylesheets and how to manipulate them. So it’s a great benefit for that workflow, but if you are used to SGML or something that lets you define sections and style them by type later on, something more like MMD with its XML based method could do what you want. Working with MMD in Scrivener is a bit like using it as a plain-text editor, but without having to avoid the rich text stuff for your own uses. All formatting will be stripped, so it can be used in an arbitrary fashion. The only thing that matters is the syntax, which is easy to learn. It’s basically just Markdown; the Multi- part of it is the extra book-ish features and extended export options.
The only catch is that this integration will be only moderately controlled by the compiler. Most of the processing is done after the compiler creates the MMD document, and takes place either in the MultiMarkdown binaries or the optional XML post-processing off of the XHTML file it creates. That has its advantages of course. It means any work you do to customise or expand the capabilities of your compiled documents can also be used for smaller files you create, too, outside of Scrivener.
In a nutshell that’s it. If you want a fully scripted back-end with true semantic association between parts and formatting, then you’ll have that too.