Page 2 of 2

Re: Styles: how they will be?

Posted: Sat Nov 16, 2019 10:32 pm
by lunk
Jack Daniel wrote:First, it IS INDEED necessary to associate a style with every paragraph if you want dialogue to have a different format than narration in fictional prose text, or at a minimum associate a style with one or the other of those.

No, it’s not. You don’t need to have a Scrivener style associated with every paragraph. Every paragraph can still have a specific formatting, different for fictional prose and dialogue. The most common type of paragraph would be "no style" and the other would have a style associated, and the "no style" would have the format you decide in Preferences, while you write. When you Compile you decide in the same way the format of the standard "no style" text and another format for the styled text. Simple.

Re: Styles: how they will be?

Posted: Sun Nov 17, 2019 12:26 am
by kewms
Jack Daniel wrote:Second, this will be the third time I've been compelled to repeat that I am fully aware what the complications can be, and that this is completely beside the point of solving this issue. The fact that it brings complications has nothing to do with the fact that it is still a problem. Did I throw my hands up and whine about it? No, I put my head down and fixed it.


I have to disagree here.

Your manuscript is your manuscript. Use whatever formatting facilitates your goals.

But if you choose a formatting approach that is directly opposed to Scrivener's design philosophy, it is perfectly legitimate for people to respond to the inevitable complications by saying, "Sorry, that's not how Scrivener is designed to work." Your opposition to Scrivener's design philosophy is not beside the point, it IS the point.

Katherine

Re: Styles: how they will be?

Posted: Sun Nov 17, 2019 9:42 am
by devinganger
Jack Daniel wrote:First, it IS INDEED necessary to associate a style with every paragraph if you want dialogue to have a different format than narration in fictional prose text, or at a minimum associate a style with one or the other of those. That's the very definition of a typographical 'style'—being unique and displaying type differently from another style, and that is exactly what I'm trying to do.


Some history that I don't know if you are aware of (apologies if you do, but others who are reading this thread may also not know/remember this history): originally, in the Scrivener 3 beta for Mac as styles were being introduced, for a time Scrivener operated under the concept that every bit of text *did* have to have a style. That ran into later complications for a few specific use cases that existing Scrivener users depended on, the details of which I do not remember at this time because I am not one of those affected, and KB realized that it could be solved by not requiring a style.

Note here that when Scrivener uses the word style, it means something very specifically in terms of the metadata that is stored with the data. Scrivener uses RTF as its base data format. Native RTF (if I remember this correctly) doesn't support the concept of styles at all; when you change styles in a program, it embeds the necessary codes to represent all the attributes that style sets in the raw RTF.

But what happens when you change that style definition? In a program like Word, the styles are defined in one place and then when you apply a style, the document metadata for that text shows the new style (and the switch back when that style ends). This is why Word has its own data format that is not RTF (modern Word is XML, previous Word formats were a weird super-set of RTF but with more differences, and they produced incredibly fragile, corruption-prone documents as a result.) Because of that, when you change the style definition in a Word document, Word doesn't have to go update the actual text data in the document; it changes the style definition XML and re-renders the changed style everywhere appropriate. If you save that Word document to RTF, though, it has to go convert all those style references to the actual text properties they represent. (I believe, but could easily be wrong, that Word will save an enhanced version of RTF that keeps the style references intact so they can be re-read by Word if you read that RTF document back in, but it has to add in the explicit property data everywhere so the document can also be read by programs that only read standard RTF.)

So that's the fundamental problem that Scrivener had to solve -- being based in RTF, if you use styles, you basically lose those style definitions the minute you save the RTF document (without doing custom extensions like Word) as they are converted to the corresponding sets of properties. And that's how text presets worked in Scrivener 1 and 2 -- they were literally just pre-set bundles of text properties, which got stamped all together when applied, but if you changed the preset definition, none of the previous uses in your project got updated because there was no definition to tie them together.

So in Scrivener 3, styles serve two purposes: they allow you to use styles like Word and other programs where the definition of the style and the application of the style have a link, so that if you change the style definition you change the application everywhere that style is used; they also make it easier for the Compiler to pass style information on to formats (like Word, etc.) that understand and use that information. But, KB determined that putting styles on everything caused deep problems for specific use cases.

So now Scrivener 3 has the "default formatting" on a per-project basis. When you write a new chunk of text, it will use this default formatting (unless something else overwrites it) but it *does not have a style associated with it*. So if you change this default formatting, it acts like the old Scrivener 2 -- you change the way future text appears, but you don't change any of the existing text -- the default formatting is just a preset. Anything you do tag with a style works the way we expect styles to work -- update the style definition, all text marked with that style changes. This is important when it comes to compile time, because the style names get passed through (and if I name them to same as the styles in my style sheet in my target format, I can override the Scrivener-provided style definitions and use an external style sheet without having to duplicate all the intricacies of those style sheets in Scrivener). And if I remember correctly, everything that *isn't* formatted with a style will get passed through Compile using the Compile format defaults, and I *believe* that it gets tagged as Normal style in outputs that expect styles (or at least, there is a way using the Compiler overrides to make that happen) -- so in my output format, I get the effect of all of the rich style awareness.

One example I have seen of how this works in a more complicated setting. Our writer wants to have drop caps for the first paragraph at the start of every new section, with every subsequent paragraph merely having an indent. Rather than try to do elaborate drop caps in Scrivener, they simply indicate this by not indenting the first paragraph of each section. They are using a fairly common setup -- folder per chapter, a separate document for each section in the chapter.

To get this to work, they set up Scrivener so that the default project format is the desired typeface, size, with no leading indent. They then define a NonLeadingPara paragraph style that is the same settings, except that it includes the desired leading indent; this style has the checkbox marked so that following paragraphs receive the NonLeadingPara style. Now, when they create a new section and begin typing, Scrivener does not apply a style, so that first paragraph receives the default formatting (no indent). When they begin the second paragraph, they apply the NonLeadingPara style, and every subsequent paragraph they type in that section automatically uses that style. If they have specific lines of dialogue or other internal formatting that they want to distinguish, they set the appropriate styles for those and apply them as necessary.

Now, that's *one* way to solve their problem, and it has a few advantages, but they can also reverse it -- the leading paragraph gets the style definition with no leading indent, and the default formatting gets the leading indent. NOW...they only apply the style to the first paragraph in the section. Any other paragraphs they write don't need a style unless they have those other styles they need to apply. And now, given how they set up their Compile format, the leading paragraphs get their style passed into the target Word doc, but the majority of the body paragraphs (which have no style) become Normal style in Word.