I worked in technical writing for a number of years and understand how styles work.
After being disappointed with 1.x W10 with how styles worked, I was excited to try Mac styles in 3.x
I was sorely disappointed.
Trying to do the most basic things with styles is just…confusing…
It really feels like the developer/development team needs to take a basic course in desktop publishing in order to understand what styles are, how they work, and how to use them.
Or, abandon them altogether for the claim that scrivener is a writing tool, and not a formatting/publishing tool, which message I received clearly when going through the 1.x tutorial on windows.
As a writing and information organization tool, it is probably unsurpassed.
As a publishing tool, it’s going to cause massive headache at least.
This paragraph from the manual alone:
“Styles, Tables and Lists
Owing to technical conflicts that exist between the style system and how lists (using bullets or numbering) and tables are constructed, paragraph styles should not be expected to work properly within them, or to modify how they work. Character styles will work as expected within table cells and list lines, so if the intention is to modify the character formatting for an entire cell, you would be better off using character styles for such things as table headings or key bullet points.”
…shows that the creator does not understand how styles work in every other competent DTP in creation.
Bulleted and Numbered lists are paragraph styles. They don’t conflict with them!
You should assign bulleted and numbered lists from within styles.
And having a no style is a crazy choice…because everything is styled as something in a document, (meaning it has an appearance), whether the writer was conscious of using styles or not.
Just copying the Word system would have been preferable, if we are going to use styles.
For example, indentations should be defined at the style level. Not in the format…huh? place…
Same with line spacing. Anything to do with presentation, as opposed to content.
Styles are meant to separate content from presentation by classifying all content.
I understand Scrivener is trying to be all things to all people. Including myself. It’s unfortunate that this is such a weak point of an otherwise amazing product.
It’s not trying to be verything. It’s providing a way to produce reasonably formatted text for output, to create a starting point for a Desktop Publishing software.
No style is actually a very smart invention, i.e to separate the standard text which does not have any inherent style when you compile the text, from the special, styled parts that deviate from the rest.
Your way of arguing seems to me to assume that Word is a standard that all other software should adhere to.
Everything has an appearance, but not everything has (or needs) an assigned Style. That’s the entire point. If you are attempting to assign Styles to everything in your project, you are creating unnecessary work and frustration for yourself.
The “Word approach” to Styles is not relevant to Scrivener because Word has nothing resembling the Compile function. The Compile function, among other things, allows you to use completely different stylesheets for the writer (you) and the reader (the output document). As such, it is a fundamental reason why Scrivener’s Styles work the way they do.
I’m not sure where that claim is made—we are quite careful to leave any implications of publication away from what the core software is meant to accomplish. It fundamentally remains a pure writing tool.
The only main exception is its ebook output system, which is probably right up there in terms of what other tools are capable of. You have full control over the CSS, and with a knowledge of how content is produced, deep control over the HTML structure itself. One could do just about anything they want for an ebook, rivalling even lower-level tools like Sigil, or assembling book manifest content by hand in a coding editor.
For the rest though, RTF and PDF and all that—yeah, you aren’t really supposed to be trying to use this as a desktop publishing tool. If you can make it work for what you need, all right, but it’s about as misguided as using MS Word for publishing, frankly. It’s not something anyone in a professional capacity as a book designer would do.
Or it means exactly what it says: that these are technical limitations in the programming toolkit rather than design decisions. One can be aware of what is proper versus what is not possible, all at once. In fact I would say that the paragraph you quoted wouldn’t exist if one were unaware of what is proper. That a warning is given here at all, should be a strong indication there is an awareness.
In some systems, sure. That isn’t a universal statement though. In some systems listing tools are general purpose and not coupled with styles, so to speak, but rather the stylesheet changes how they work from some central definition. XML and LaTeX for example, do not have “paragraph styles” in the sense you seem to be using the term, and a list will be simply a functional construct which can have its appearance and layout modified by the applied stylesheet or document class. Indeed, within how these systems work, to say that a list is a form of paragraph is illogical, much like trying to assert that a caption is a form of paragraph, or a figure.
It’s not so crazy once you consider Scrivener’s design intent here: that one needn’t be forced into learning how to use styles unless they really want or need them. It’s designed to be as equally useful to writers who have no clue what any of this stuff is about. Someone can just type into the editor, never once changing formatting settings, and then easily switch between Manuscript-Courier and Paperback, achieving a radically different document design based on whether they are proofing for their own comfort, or submitting the formal manuscript. I.e. it achieve what styles in word processors do, but without the edict that everything must be styled in order to accomplish that.
It is also designed, incidentally, to be easily transformed into a properly styled document on output, if that is what you need. You simply apply a body paragraph style to such text in the compiler. Now, I would say that in general it could use some improvement there, and we could go into the many ways in which that is true—but these would all go back to my advocating for using Scrivener’s technical systems of output (like DocBook and LaTeX) if you really need well-formed documents. It’s either that, or spending a week or two polishing the document off in the final environment (just like you would have done in v1).
Well now you just have me confused, as I wouldn’t consider Word to be any sort of pedestal upon which desktop publishing design should be referenced.
At the risk of sounding like a broken record, that may be how Word solves the problem, but that is not how the problem is solved in other publishing systems. In LaTeX for example, I don’t use “paragraph styles” for the main text, the main text is much closer to Scrivener’s no style, in fact. The indenting and spacing policy for paragraphs is a transformation done to such text dynamically, based on the context of objects around it.
To my mind, this is a much more elegant approach than Word’s anyway. For how I work, I can have a single block of text, and if I drop a block quote or figure in the middle, the indentation and padding policies of the paragraph following those elements automatically adjusts when the document is typeset. With Word I would have to go in and manually assign a “Body - No Indent” style to each paragraph following such elements, and manually correct those assignments if elements are inserted or moved around, later. Yuck.
Crucially, Scrivener is much closer to that ideal, where you don’t bother with petty little details like formatting indents in the writing environment. Rather there is a policy switch in the compile settings which determine how indenting works globally, upon all body text. That is what a Format is. So to say it shouldn’t be using Formats to drive formatting is a very Word-centric way of thinking.
But that is exactly how Scrivener works. You may not be making the conceptual connection here, that the compiler is in a large sense the stylesheet application phase (and as noted, it can be literally that as well). You write without thinking about any of that stuff, and leave these details up to the compiler.
Overall it sounds to me as though you are familiar with a different kind of document design that Scrivener was based upon (namely, WYSIWYG), and have come to believe that is the only way books are made. Scrivener is, as I’ve described above, much closer to the DocBook XML / LaTeX / HTML / Org-Mode way of doing things, where the text itself is defined structurally, purely for its semantic function and without any regard for formatting. As with these systems, the actual document design is implemented as part of the production phase, as a mechanism you run by feeding content through it, and ending up with an output document of some format.
To conclude, I wouldn’t say that much has changed since version 1, at a philosophical design level. It’s pretty much all the same, the main difference that has arisen over the past decade is that it is now much more capable of taking your raw content and turning it into something much closer to how you might eventually want it to look. It removes some of the busywork, if you are inclined to have it do so—but ultimately you could use it just like you did version 1, very simply, and without learning much of how the compiler works, and then spending that time instead manually formatting the document in a DTP.
I had a problem with “no style” at first until I realized “no style” is actually the default paragraph format (style?) as defined in Scrivener Preferences. Having styles available to make things like headers stand out for these old eyes made life a lot easier than it was before they came to Scrivener. I’ve gotten so using Scrivener Styles is transparent to the writing process. I only use a few but I don’t even have to think about the key code, it just happens.
I now use Styles to format things in my fiction writing like text messages, or quoted newspaper articles. That actually enhances the writing process with out spending much time making it happen. Works great it does.
Wow, I signed on to see if there was an answer to my problem and encountered kind of a hostile discussion. Sorry to see people angry.
Here’s my issue: I bought Scrivener because I was embarking on a larger writing/research project and I like the built-in organization of this.
I also host a radio show, and it dawned on me that I could keep everything for the show in a Scrivener doc. Or file. Or whatever. I can do pre-interviews. I can create different pages for different interviews. I can keep research material. It’s a lot more organized than throwing everything into a Google doc. This was the answer to a question I never knew I had!
Until I got to the point where I had to write out the questions for the show. I use numbers. And the auto numbering tool works, but not well enough. It frequently will lose the formatting. It don’t do sum questions - an “a” under question “1” for example. And I spend more time trying to keep the numbers in order than I do actually writing questions. So I ended up going back to a Google doc to write my questions. Which kind of defeats the purpose of having things in one place.
I’m not asking for the world, just a stable bullet and numbering system. That would make things a lot easier to organize in my larger project, too, since I tend to think in outlines.
OK, thank you very much. Hope you all are staying healthy and getting some good work done as we are forced to be inside.
Until I got to the point where I had to write out the questions for the show. I use numbers. And the auto numbering tool works, but not well enough. It frequently will lose the formatting. It don’t do sum questions - an “a” under question “1” for example.
The basic listing tool is a bit buggy, if that’s what you mean. Unfortunately it has been in roughly the same state since Apple released it in 2004-ish. At this point, I’m sure thousands of bug reports have been filed for it, but they haven’t made major adjustments to the text engine in general, and seem unwilling (or maybe even unable) to fix it. That said, it’s one of the better if not the best free text engines available—which perhaps says something about the overall state of complex formatting-capable text engine development.
At any rate, I think Scrivener has some different answers for what you are trying to use it for here. One of them is something along the lines of what lunk suggests, where your binder outline is more detailed, down to the questions and answers, and you then number and indent the outline on output (check out the “Enumerated Outline” compile Format for some ideas on how that could be done). Scrivenings mode can keep that way of working as seamless as editing a single text file. Section Types can differentiate between question and answer, and be formatted/numbered differently when exported.
But if hitting ⌘N instead of ↩ when you start a new question/answer seems like too much trouble, the very topic of this thread provides another solution. One of the unusual things that Scrivener’s styling system does, is allow for the attachment of boilerplate text around the styled text. With that approach, you could say something along the lines of, “prefix each paragraph of text within this styled block with an alphabetical counter”.
I take a similar approach in a sense—I use the listing tools sometimes, but I have the lists converted to Markdown as an abstract list rather than specifically formatted. For me it is the conversion and application of a stylesheet to the document that generates the design for the list. Thus, even if Scrivener’s numbering in the list is inaccurate, it doesn’t matter, because none of the tools I use require accurate numbering in the writing environment. All the writing environment requires is a statement that this line is a list element. Simple, and the kind of thing I can get from just typing in “1.” at the beginning of each line in the list, too.